Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

10.
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/

21.
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

44.
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

47.
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.
Scale
Scrum
Beyond
Your
Team
• “We
have
worked
with
thousand
of
organizaEons
that
are
aMempEng
to
become
more
eﬀecEve
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.”

60.
Product
Development
Process
• The
CIF
product
development
process
lays
out
the
ﬂow
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
ﬂows
into
and
out
of
the
Product
Backlog.

61.
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
eﬀecEveness.
• Your
overall
agility
is
compared
to
that
in
other
organizaEons.
• Ways
to
increase
the
eﬀecEveness
for
conEnuous
improvement
are
devised
and
applied.

62.
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,
ﬁnance,
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.

70.
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

71.
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
eﬀort
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

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

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

74.
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
oﬀers
a
counter-­‐intuiEve
innovaEve
modern
approach.
SAFe
oﬀers
something
familiar.
David
J.
Anderson

75.
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.

76.
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

79.
SAFe
:
infanElism
of
…
Put
brutally
SAFe
seemed
to
be
PRINCE
II
camouﬂaged
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
diﬀerent
from
a
PERT
chart
and
in
general
what
we
had
is
an
old
stale
wine
forced
into
shiny
new
wineskins.
Dave
Snowden

80.
SAFe
:
infanElism
of
…
My
strong
and
increasingly
passionate
argument
was
that
SAFe
is
not
only
a
betrayal
of
the
promise
oﬀered
by
AGILE
but
is
a
massive
retrograde
step
giving
the
managerial
class
an
excuse
to
avoid
any
signiﬁcant
change.
Dave
Snowden

81.
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

85.
Culture
>
Process
• Shu-­‐level
Scrum
can
get
you
out
a
ditch,
but
won’t
make
you
ﬂy.
– 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.