Perché parliamo di Scaling Lean Agile? Ci sono due aspetti primari inerenti lo scalare delle tecniche agili a livello di Enterprise che è necessario considerare. In primo luogo lo scalare delle tecniche agili a livello di progetto per affrontare le sfide peculiari che i team di progetto devono affrontare. In secondo luogo è lo scalare la vostra strategia agile attraverso l'intero reparto IT, in modo appropriato. E' abbastanza semplice applicare Lean Agile su una manciata di progetti, ma può essere molto difficile far evolvere la cultura e l’intera struttura organizzativa per adottare appieno il modo agile di lavorare. Lean e Agile (in particolar modo metodologie come Scrum e XP) hanno pienamente dimostrato il loro valore a livello di team. Cosa succede però nel momento in cui tentiamo di utilizzarle in contesti reali più complessi? Nelle reali organizzazioni che caratterizzano un’importante parte del panorama dell'IT in Italia? Muovendosi dal livello dei team verso il livello dell'organizzazione si incontrano una serie di problematiche più complesse e per un certo verso nuove. Ecco quindi l'importanza di conoscere valori e principi che sono alla base del tema del Lean Agile Scaling. Esistono parecchi modelli che negli ultimi anni si confrontano con le realtà delle organizzazioni. In questo talk tratteremo a livello olistico questo tema e confronteremo alcuni di tali modelli di Scaling Lean Agile, quali: Scrum standard (Ken Schwaber, Mike Cohn, ...) – il modello di Larmann & Vodde - SAFe – Disciplined Agile Delivery di Scott Ambler – Path to Agility (Ken Schwaber). Inoltre verranno affrontate e discusse le esperienze personali effettuate in diverse società in fase di adozione o utilizzo su larga scala di Lean Agile.

1. Fabio
Armani
OpenWare

2. Agenda
• Agile
Development
• Extended
Lean
Agile
Frameworks
• Disciplined
Agile
Development
(DAD)
• Scaling
Agile
Framework
(SAFe)
• Agility
Path
+
CIF
• Large-­‐scale
Scrum
• ConsideraEons
• Conclusion
2

3. Agenda
• Agile
Development
• Extended
Lean
Agile
Frameworks
• Disciplined
Agile
Development
(DAD)
• Scaling
Agile
Framework
(SAFe)
• Agility
Path
+
CIF
• Large-­‐scale
Scrum
• ConsideraEons
• Conclusion
3

4. What
Agile
is
NOT
!!

7. Accelerate
Eme
to
market
Managing
changing
prioriEes
BeMer
align
IT/Business
Increase
producEvity
Enhance
soOware
quality
Project
visibility
Reduce
risks

11. Agile
Overtakes
Waterfall

12. Improve
things
with
Scrum
Remove
waste
• Technical
debt
• Unnecessary
documentaEon
• Unnecessary
requirements
• Unused
requirements
• Architecture
that
must
be
reworked
Improve
producEvity
• Collocated,
self-­‐organizing
teams
• Cross-­‐funcEonal
teams
• FTF
communicaEons
• Improved
decision
making

13. Technical
Prac6ces?
Project
Ini6a6on?
Release
into
Produc6on?
Operate
in
Produc6on?
Enterprise
Disciplines?
Project
Selec6on?

14. Lean
Agile
@Enterprise

15. Does
Agile
Scale?
YES
Scaling:
• The
majority
of
agile
teams
are
geographically
distributed
in
some
manner
• OrganizaEons
have
reported
successful
agile
programs
of
500+
people
• One
third
of
agile
teams
are
in
regulatory
situaEons
• 75%
of
organizaEons
doing
agile
are
doing
so
on
medium
complexity
or
greater
projects
• 17%
of
organizaEons
are
successfully
applying
agile
in
outsourcing
situaEons
• 78%
of
teams
are
working
with
legacy
systems
• 32%
of
organizaEons
report
successful
interacEon
between
enterprise
architects
and
agile
teams
• 11%
of
organizaEons
report
that
their
governance
strategy
works
well
with
agile
teams
(yikes)
Source:
• DDJ
November
2009
State
of
the
IT
Union
Survey,
www.ambysoO.com/surveys/

16. Small-­‐scale
vs
Large-­‐scale

17. Small-­‐scale
vs
Large-­‐scale

18. Small-­‐scale
vs
Large-­‐scale

19. Small-­‐scale
vs
Large-­‐scale

20. Small-­‐scale
vs
Large-­‐scale

21. Small-­‐scale
vs
Large-­‐scale

22. Small-­‐scale
vs
Large-­‐scale

23. Problems
of
Scaling
§ SoS
–
Scrum
Of
Scrums
– Becomes
more
difficult
aOer
6
or
so
Teams
– Planning
&
Ceremonial
Events
conflict
§ Doesn’t
really
address
a
Porlolio
&
Program
View
– SEll
thinks
of
smaller
“projects”
– Planning
Roadmap
horizons
are
sEll
short
§ Fails
to
recognize
that
Waterfall
sEll
exists
§ Governance
&
Authority
start
to
fail
– No
Clear
Content
Authority
once
you
scale
to
a
Program
or
Porlolio
level
– Who
resolves
prioriEes
across
dozens
of
teams?
– Who
then
drives
releases?

24. 24
Problems
of
Scaling
§ ReporEng
&
Metrics
aren’t
sufficient
across
large
numbers
of
teams
or
programs
§ TradiEonal
sources
of
informaEon
(Scrum/Agile
Alliance)
aren’t
mature
to
help
this
– Note:
In
Jan
‘2013
Ken
Schwaber
introduced
CIF
–
ConEnuous
Improvement
Framework

25. Agenda
• Agile
Development
• Extended
Lean
Agile
Frameworks
• Disciplined
Agile
Development
(DAD)
• Scaling
Agile
Framework
(SAFe)
• Agility
Path
+
CIF
• Large-­‐scale
Scrum
• ConsideraEons
• Conclusion
25

26. What
Should
a
Scaled
Framework
Address?
§ Mul6ple
Agile
Teams
– Should
be
able
to
handle
dozens
of
teams
(Scrum
starts
to
break
around
7)
– IncorporaEon
of
XP
Engineering
pracEces
§ Waterfall
Teams
– They
sEll
exist.
Not
everything
can
be
Agile
§ Program
Level
planning
and
views

27. What
Should
a
Scaled
Framework
Address?
§ Governance
and
shared
resources
(like
Enterprise/System
Architects,
UX,
etc.)
§ Specialized
teams
for
Release
planning,
system
integra6on
§ Clear
content
authority
§ PorPolio
Management
and
the
management
of
WIP

29. DAD
-­‐
Disciplined
Agile
Delivery

30. The
Disciplined
Agile
Lifecycle:
An
extension
of
Scrum

31. Concept:
The
Agile
3C
Rhythm
Incep6on
Coordinate
Construc6on
Collaborate
Transi6on
Conclude
Release rhythm
Itera6on
Planning
Coordinate
Development
Collaborate
Stabilize
Conclude
Iteration rhythm
CoordinaEon
MeeEng
Coordinate
Daily
work
Collaborate
Stabilize
Conclude
Daily rhythm
The Coordinate-Collaborate-Conclude rhythm occurs at several scales on a DAD project:

32. The
IncepEon
Phase

33. Typical
ConstrucEon
IteraEon

34. Typical
day
during
construcEon

35. The
TransiEon
phase

36. * Slide Courtesy of IBM
Agile Scaling Factors

37. DAD
-­‐
Disciplined
Agile
Delivery
• Decision
oriented
framework

39. SAFe
-­‐
Scaled
Agile
Framework

40. SAFe
-­‐
Scaled
Agile
Framework

41. Roots
of
the
Scaled
Agile
Framework

42. Scaled
Agile
Framework
–
Big
Picture

43. Agile
Teams

44. Scale
to
Program
Level

45. Scale
to
Porlolio

47. SAFe
–
Scaling
Agile
Framework
• PrescripEve
framework

48. DAD
vs
SAFe

54. Evidence-Based Management (“EBM”):
• Roots in the medical practice.
• The application of direct, objective evidence* by managers
to make decisions.
• For software development, EBM is employed to maximize
the value of software to the entire organization.
A Matter of Managerial Culture
Evidence, broadly construed, is anything presented in support of an assertion:
• Strongest type of evidence is that which provides direct proof of the validity of the
assertion.
• Weakest type of evidence is that which is merely consistent with the assertion, but
doesn’t rule out contradictory assertions, as in circumstantial evidence.
*Source: Wikipedia

55. Direct Evidence of an Organization’s Value

56. Outcome Is Measured for Direct Evidence Of Value
Current
Value
Ability
to
Innovate
Time
to
Market
Release
Frequency
Release
StabilizaEon
Cycle
Time
Installed
Version
Index
Usage
Index
InnovaEon
Rate
Defects
Revenue
per
Employee
Employee
SaEsfacEon
Customer
SaEsfacEon
Product
Cost
RaEo

57. Circumstantial evidence is
evidence that relies on inference to
connect it to a conclusion of fact,
allowing more than one explanation
to be possible:
• Usually accumulates into a
collection so the pieces become
corroborating evidence.
• Explanation involving
circumstantial evidence
becomes more valid as proof of
a fact when the alternative
explanations have been ruled.
Entry points to collect circumstantial evidence

58. Diagnosing circumstantial evidence in organizational patterns
Process
Produc6vity
Value
Quality
Enterprise
• Scrum
• Self-­‐
organizaEon
• Product
Backlog
• Sprint
Planning
• Daily
Scrum
• Sprint
Review
• Sprint
RetrospecEve
• Scaling
Scrum
• DefiniEon
of
Done
• TesEng
• Clean
code
• Test-­‐Driven
development
• ConEnuous
IntegraEon
• Emergent
Architecture
• Accountability
• Transparency
• Product
Backlog
• Alignment
• Release
planning
and
orientaEon
• Porlolio
Management
• Engineering
standards
• Architecture
• QA
• ALM
• CommunicaEon
• OrganizaEon
• Culture
• People
PracEces
• Sales
• Lean

59. Relating value to organizational patterns
Informs
priority
Measure
Diagnose
Improve
Influences
Outcomes
More at http://evidencebasedmanagement.org

60. EBM measures the
value of the
organization. EBM

61. EBM diagnoses
likely contributors,
and discovers
capabilities
you can build on.
EBM

62. EBM helps you
improve by
using evidence as
a driver of change
EBM

63. Agility Path implements
Evidence-Based
Management
Repeat

64. Agility
Team
• Enterprise Product Owner
– Domain Product Owner
– Product Owner
• Enterprise Change Team
– Domain Change Team
– Change Team
• Enterprise Scrum Master
– Domain Scrum Master
– Scrum Master

65. Agility
Path
Events
• Sprint
• Sprint Planning
– Functional Change
– Sprint Goal
• Weekly Scrum
• Evaluation
– Sprint Review
– Sprint Retrospective

66. Agility
Path
ArEfacts
• Practice Backlog
• Sprint Backlog
• Evaluation Backlog
• Increment of Change

67. Agility
Path
Metrics
• Agility Index
• Agility Acceleration

69. Scale
Scrum
Beyond
Your
Team
• “We
have
worked
with
thousand
of
organizaEons
that
are
aMempEng
to
become
more
effecEve
and
more
agile.
• They
usually
start
by
implemenEng
Scrum.
• Then
they
are
faced
with
the
issue
of
how
to
get
the
most
out
of
their
investment
in
Scrum.
• They
wonder
how
to
manage
its
scaling
throughout
the
organizaEon.”

71. CIF
Overview
• CIF
consists
of
two
interacEng
processes:
product
development
and
con6nuous
improvement.

72. Product
Development
Process
• The
CIF
product
development
process
lays
out
the
flow
of
work
through
the
major
product
development
funcEons
of
product
management,
program
management,
and
product
development,
based
on
Scrum.
• These
are
then
integrated
into
porlolio
and
product
family
management
for
mulEple
products
and
systems.
• The
work
flows
into
and
out
of
the
Product
Backlog.

73. ConEnuous
Improvement
Process
• The
CIF
con6nuous
improvement
process
implements
new
agile
pracEces
into
the
product
development
process.
It
periodically
captures
metrics
and
pracEce
usage.
• PaMerns
of
metrics
and
pracEces
are
assessed
for
dysfuncEon
and
effecEveness.
• Your
overall
agility
is
compared
to
that
in
other
organizaEons.
• Ways
to
increase
the
effecEveness
for
conEnuous
improvement
are
devised
and
applied.

74. Process
InteracEon
• CIF
is
oriented
around
two
databases:
– Metrics
-­‐
are
implanted
in
the
product
development
process
and
a
baseline
is
created.
Processes
are
periodically
sampled
to
measure
change
in
producEvity,
quality,
value,
agility,
and
key
performance
indicators.
– Prac6ces
-­‐
that
maximize
value
and
eliminate
waste
are
applied
to
change
your
current
processes.
They
are
organized
by
the
business
funcEons
of
product
development,
sales,
markeEng,
finance,
human
resources,
and
customer
support.
These
pracEces
are
ordered
and
tracked
in
the
pracEce
backlog
so
their
progressive
adaptaEon
and
implementaEon
conEnuously
improve
your
organizaEon,
as
reported
by
the
metrics.
PracEce
details
are
referenced
from
a
pracEce
database.

76. Scaling
Lean
&
Agile
Development

77. Scaling
Lean
&
Agile
Development
• Large
Scale
Scrum
is
Scrum:
change
implicaEons
• Fractal
structure
• Feature
teams
vs
Components
Teams
• Lean
Concepts
and
Principles
• Complex
Systems
• Queues
theory

82. Scaled
Lean
&
Agile
• Empirical
oriented
framework

83. Agenda
• Agile
Development
• Extended
Lean
Agile
Frameworks
• Disciplined
Agile
Development
(DAD)
• Scaling
Agile
Framework
(SAFe)
• Agility
Path
+
CIF
• Large-­‐scale
Scrum
• Considera6ons
• Conclusion

85. Ken Schwaber

86. Ken Schwaber
co-founder of Scrum

87. unSAFe
at
any
speed
Many
organizaEons
will
open
their
checkbooks
for
SAFe
and
its
partners.
I
suggest
that
they
measure
the
improvement,
as
that
is
the
job
of
management.
Investments
are
supposed
to
have
returns.
Ken
Schwaber

88. unSAFe
at
any
speed
• Measure:
– Cycle
Eme
–
quickest
Eme
to
get
one
feature
out
– Release
cycle
–
Eme
to
get
a
release
out
– Defects
–
change
in
defects
– ProducEvity
–
normalized
effort
to
get
a
unit
of
funcEonality
“done”
– StabilizaEon
–
aOer
code
complete,
%
of
a
release
is
spent
stabilizing
before
release
– Customer
saEsfacEon
–
up
or
down
– Employee
saEsfacEon
–
up
or
down

89. unSAFe
at
any
speed
• A
core
premise
of
Agile
is
that
the
people
doing
the
work
are
the
people
who
can
best
figure
out
how
to
do
it.
• The
job
of
management
is
to
do
anything
to
help
them
do
so,
not
suffocate
them
with
SAFe!
Ken
Schwaber

91. Abandoning
a
Process-­‐Centric
Approach
to
Improvement
David J. Anderson

92. Kanban
>
anE-­‐SAFe
The
Kanban
Method
will
coexist
with
SAFe
in
the
marketplace.
People
will
choose
between
a
modern
21st
Century
approach
to
complex
situaEons
or
a
familiar
20th
Century
approach
to
change
and
their
soOware
engineering
processes.
Choice
is
good
in
a
marketplace!
Kanban
offers
a
counter-­‐intuiEve
innovaEve
modern
approach.
SAFe
offers
something
familiar.
David
J.
Anderson

93. Kanban
>
anE-­‐SAFe
Coexistence
of
SAFe
and
Kanban
is
a
good
thing.
Providing
alternaEve
approaches
to
large
scale
business
agility
is
a
good
thing.
Both
approaches
will
carry
the
label
"Agile."
Both
will
be
marketed
as
soluEons
scaling
Agile.

94. Kanban
>
anE-­‐SAFe
Coexistence
of
SAFe
and
Kanban
is
a
good
thing.
Providing
alternaEve
approaches
to
large
scale
business
agility
is
a
good
thing.
Both
approaches
will
carry
the
label
"Agile."
Both
will
be
marketed
as
soluEons
scaling
Agile.
I
believe
there
is
considerable
irony
in
that.
David
J.
Anderson

95. Dave Snowden
father of Cynefin Framework

96. SAFe:
the
infan9lism
of
management
Dave Snowden

97. SAFe
:
infanElism
of
…
Put
brutally
SAFe
seemed
to
be
PRINCE
II
camouflaged
in
Agile
language.
SCRUM
as
an
approach
was
emasculated
in
a
small
box
to
the
boMom
right
of
a
hugely
overcomplicated
linear
model.
The
grandiose
name
of
a
dependency
map
was
applied
to
something
which
is
no
different
from
a
PERT
chart
and
in
general
what
we
had
is
an
old
stale
wine
forced
into
shiny
new
wineskins.
Dave
Snowden

98. SAFe
:
infanElism
of
…
My
strong
and
increasingly
passionate
argument
was
that
SAFe
is
not
only
a
betrayal
of
the
promise
offered
by
AGILE
but
is
a
massive
retrograde
step
giving
the
managerial
class
an
excuse
to
avoid
any
significant
change.
Dave
Snowden

99. SAFe
:
infanElism
of
…
…
Such
excuses
abound
and
allowing
these
false
linear
models
to
perpetuate
themselves
is
a
form
of
infanElism,
a
failure
to
carry
through
on
the
need
for
change.
In
parEcular
the
failure
to
realize
that
soOware
development
needs
to
be
seen
as
a
service
and
as
an
ecology
not
as
a
manufacturing
process.
Dave
Snowden

100. A
possible
way
…

108. 100%
predictability
=
0%
innova6on

110. Value
&
Impact
>
Velocity

114. Culture
>
Process
• Shu-­‐level
Scrum
can
get
you
out
a
ditch,
but
won’t
make
you
fly.
– Learn
the
rules
so
you
can
break
them.
• Healthy
Culture
heals
broken
process.
– Hack
the
culture,
and
process
will
follow.
• Agile
is
Fragile.
– It
is
only
sustainable
over
the
long
term
if
all
parts
of
the
organizaEon
are
commiMed
to
it.
• You
are
the
culture.
– Model
the
behavior
you
want
to
see.

115. Lean
from
the
trenches

116. Lean
Mindset

117. Agility
AdopEon
Rather
Than
Agile
At
Scale

120. Keep
the
values,
keep
the
principles,
think
for
yourself.

121. Keep
the
values,
keep
the
principles,
think
for
yourself.

122. Keep
the
values,
keep
the
principles,
think
for
yourself!
Ken Schwaber

124. Agenda
• Agile
Development
• Extended
Lean
Agile
Frameworks
• Disciplined
Agile
Development
(DAD)
• Scaling
Agile
Framework
(SAFe)
• Agility
Path
+
CIF
• Large-­‐scale
Scrum
• ConsideraEons
• Conclusion
124