More Related Content
Similar to Path to agility, Ken Schwaber
Similar to Path to agility, Ken Schwaber (20)
More from Xavier Warzee (20)
Path to agility, Ken Schwaber
- 2. Agility
(a·∙gil·∙i·∙ty)
–noun
1. flexibility, the capacity and capability of
rapidly and efficiently adapting to change.
2. ability
to
take
advantage
of
opportuni6es
while
controlling
risk.
The
courage
to
be
honest
enough
to
admit
that
building
soEware
is
complex
and
it
can’t
be
perfectly
planned
since
requirements
change.
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
2
- 3. Why
is
Agility
important?
• More
global
compeLtors
• More
demanding
customers
• More
complex
products
• More
features
requested
In
other
words:
Because
your
customers
demand
it.
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
3
- 4. What
are
some
specific
reasons
to
“be
Agile?”
• Improved
relaLonship
with
customers,
regaining
trust
• Flexibility
to
turn
on
a
dime
• Improved
producLvity
and
quality
• Taking
advantage
of
opportuniLes
• Early
eliminaLon
of
risk
• Early
realizaLon
of
value
• Always
knowing
exactly
where
you
are
in
a
development/deployment
cycle
• Easier
to
make
changes
• EliminaLon
of
waste
• Lean
products
that
reach
market
faster
and
are
more
targeted
• Increased
Return
on
Investment
• Engaged,
empowered
workers
• Reduced
Total
Cost
of
Ownership
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
4
- 5. But,
many
organizaLons
instead
have
…
• Releases
take
longer
and
longer.
• Release
schedules
slip.
• StabilizaLon
at
end
of
release
takes
longer
and
longer.
• While
a
release
is
being
worked
on,
it
is
very
hard
if
not
impossible
to
start
another
release.
• Planning
seems
to
take
too
long.
• Changes
are
hard
to
introduce
mid-‐release,
even
though
they
consLtute
35%
of
the
total
work.
• Quality
is
deterioraLng.
• There
have
more
and
more
arLfacts,
documentaLon,
and
process
• Death
marches
are
hurLng
morale.
• More
than
60%
of
the
funcLonality
is
rarely
or
never
used,
yet
unfilled
needs
and
commitments
conLnue
to
build
up
while
the
current
release
is
being
delivered.
Source:
Advanced
Development
Methods,
Inc.
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
5
- 6. TradiLonal
Development
Processes
Are
Not
Agile
Plan
Analyze
Design
Code
Test
Release
Waterfall!
Plan for the entire project up-front, including
requirements of all value. Nothing can be
used until project is over.
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
6
- 7. Scrum
Is
Just
TradiLonal
More
Quickly
Waterfall!
Plan
Analyze
Design
Code
Test
Release
Scrum!
Short, high value
iterations that The same work, but
Analyze
deliver valuable, Design
processed differently
Plan
Plan
opportunistic Code
Test
and on fewer
pieces of Release
requirements.!
functionality.!
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
7
- 8. Scrum
Is
a
Tool
You
Use
To
Become
Agile
Scrum!
Short, high value
iterations that
Analyze
deliver valuable, Design
Scrum
Team
Plan
Plan
opportunistic Code
Test
pieces of Release
Work done by self-organizing,
functionality.! cross-functional teams that are
highly productive, creative, and
build high quality product.!
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
8
- 9. May
I
recommend
Scrum?
Scrum
(n):
(1)
framework
within
which
people
can
address
complex
problems,
and
producLvely
and
creaLvely
develop
products
of
the
highest
possible
value;
(2)A
tool
you
can
use
to
become
Agile!
Image
source:
codecentric.de
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
9
- 10. Agile
Overtakes
Waterfall
Waterfall %
Agile %
Source: December 2008 Global Agile Company Online Survey
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
10
- 11. Improve
things
with
Scrum
Remove
waste
Improve
producLvity
• Technical
debt
• Collocated,
self-‐
• Unnecessary
organizing
teams
documentaLon
• Cross-‐funcLonal
teams
• Unnecessary
• FTF
communicaLons
requirements
• Improved
decision
• Unused
requirements
making
• Architecture
that
must
be
reworked
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
11
- 12. The
first
thing
that
Agility
requires
is
empiricism
Empirical (adjective)
1) Derived from or guided by experience or
experiment.
The
modesty
to
admit
that
you
don’t
know
all
the
answers,
and
that
is
okay.
The
best
soluLon
emerges
from
collaboraLon
with
the
team.
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
12
- 13. A
thermostat
for
soEware
development
5
MINS
Time
People
Event
Purpose:
Understand
the
power
of
empiricism
7:00
-‐
8:00 5 Room
setup
Situa<on:
You
are
in
charge
of
keeping
a
20
x
8:00
-‐
9:00 50 Breakfast,
ConLnental
buffet
style,
Lyzure
Amalgamated
40
room
in
this
building
at
a
constant
22C
temperature
through
the
day.
The
room
does
not
9:00-‐
10:30 55 MeeLng
-‐
Lyzure
have
a
thermostat.
Amalgamated
10:30-‐
11:00 55 Coffee
break
At
the
start
of
the
day,
8:00
am,
you
have
to
set
the
heaLng,
air
condiLoning,
venLng,
and
blinds
so
that
11:00-‐
12:30 55 MeeLng
-‐
Lyzure
Amalgamated
they
will
adjust
themselves
at
the
appropriate
Lmes
12:30-‐
1:00 5-‐20 Setup
and
next
meeLng
to
maintain
this
temperature
throughout
the
day.
arriving
1:00-‐
3:00 50 MeeLng
-‐
Rexxus
Ltd.
Ques<on:
What
variables
will
you
have
to
take
3:00-‐
3:30 50 Coffee
break
into
account
to
know
the
senngs?
(hint:
number
of
people
in
the
room
will
be
one
variable).
3:30-‐
5:30 70 MeeLng
-‐
Rexxus
Ltd.
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
13
- 14. Controlling
temperature
isn’t
that
complex,
but
there
are
a
lot
of
things
to
plan
for!
Variables
might
include,
for
any
Lme
during
the
day:
• number
of
people
in
room
• metabolism
of
each
person
• acLvity
of
each
person
• opening/closing
of
doors
• weather:
including
sun,
clouds,
and
outside
temperature
• temperature
of
adjoining
rooms
• construcLon
material
of
the
building
• floor
of
the
room
• will
food
be
served,
when,
what
type,
and
how
much
• temperature
of
food
brought
into
room
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
14
- 15. Dimensions
Of
Complexity
Simple: Everything is
known
Complicated: More is
Patterns
Weather
known than unknown
Complex: More is
unknown than is known
Chaotic: Very little is
known
Building
Construction
Source:
Ralph
Stacey,
University
of
Herfordshire
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
15
- 16. Empirical
processes
adapt
to
the
future
• Variables
are
ignored.
Actual
temperature
drives
senng
of
air
condiLoning,
heaLng,
blinds.
• Frequent
inspecLon
&
adaptaLon
(JIT)
rather
than
predicLve
planning
• Based
on
“actuals”
rather
than
predicLons
• Requires
transparency
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
16
- 17. The
first
thing
empiricism
needs
is
transparency
Transparency (adjective)
1) Easily seen through, recognized, or
understood.
2) All aspects are equally and commonly
understood by all observers
Most
organizaLons
struggle
with
transparency.
It
requires
trust,
courage
and
a
lot
of
collaboraLon.
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
17
- 18. Quality:
A
Developer’s
POV
• I
can
readily
understand
the
soEware
and
where
&
how
things
happen;
• When
I
change
or
add
to
part
of
the
soEware,
there
are
no
unintended
or
poorly
designed
dependencies;
• I
can
read
the
code
without
looking
for
tricks
or
poorly
defined
and
labeled
variables
or
data;
• I
don’t
need
the
person(s)
that
wrote
the
code
to
explain
it
to
me;
• There
are
a
full
set
of
(automated)
tests
to
check
that
the
funcLon
works
as
expected;
• When
I
change
something
and
add
to
the
tests,
I
can
check
that
the
enLre
change
and
product
conLnues
to
work;
• How
things
work
and
hang
together
is
tranparent;
and,
• Standard,
well-‐known
design
principles
have
been
adhered
to.
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
18
- 19. Green
Field
SoEware
Product
Backlog Velocity (done work over time)
(work)
Time
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
19
- 20. Exercise
The
SituaLon:
The
Assignment:
• You
are
a
developer
at
xyz
co,
•
What
work
would
you
have
to
do
building
life-‐criLcal
products.
to
turn
the
requirements
into
a
• Your
Scrum
team
is
one
of
seven
“done”
increment?
working
on
a
new
release
of
one
•
If
you
were
developing
a
“done”,
product.
potenLally
shippable
increment,
• Your
team
is
going
to
select
what
would
your
definiLon
of
product
backlog
to
turn
into
“done”
be?
Would
it
include,
for
something
done
(no
more
work
example,
refactoring?
What
else?
remains,
potenLally
shippable)
within
a
two-‐week
iteraLon.
• Each
team
has
all
the
skills
to
fully
develop
the
requirements
into
a
“done
increment.”
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
20
- 21. Exercise
(Cont.)
Did
your
definiLon
of
“done”
include
these?
Why
not?
•
Performance
tesLng
•
Stability
tesLng
•
Refactoring
•
Immunological
response
tesLng
•
IntegraLon
with
the
work
of
the
other
six
teams
•
IntegraLon
tesLng
with
the
work
of
the
other
six
teams
so
the
increment
is
the
totality
of
all
seven
teams
•
Release
notes
•
InternaLonalizaLon
to
the
six
cultures
where
the
product
will
be
sold
•
User
acceptance
tesLng
•
Regression
tesLng
•
Code
reviews
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
21
- 22. StabilizaLon:
What
Undone
Gets
You
Plan
Plan
Develop
Plan
Develop
Plan
Develop
Stabilize
Plan
Plan
Develop
Plan
Develop
Plan
Develop
Stabilize
Undone
Undone
Undone
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
22
- 23. Case
Study:
TransCanada
Pipelines
• After three Sprints, Product Owner was delighted.
She wanted us to continue, but she wanted us to
implement the first three increments so her
department could start using them.
• We told her that she couldn’t. She asked why not.
We said that we weren’t done. She said that it
looked done. We said, yes, but not that type of
done. She asked how long it would take to go
from our type of done to the done that would be
usable by her.
• Transparency was not present and trust was lost.
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
23
- 24. StabilizaLon:
Plan
Vs.
Reality
Plan!
9 Sprints, 3 release candidates and then release.!
800-person development organization.!
P D P D P D RC P D P D P D RC P D P D P D RC Release
Actual!
The release candidates were presentation of partially working functionality from the
code branch for each team. A five+ month stabilization was required prior to release.!
“Inadequate performance” was a bug logged in the first Sprint.!
P D P D P D RC P D P D P D RC P D P D P D RC Stabilization!Release
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
24
- 25. Impact
Of
Integrated
“Done”
• 120 people, 18 teams!
• Release 1: ! Planned!
Release!
• Each team produced Date!
“done” increments each
Sprint, but they were not Release 1!
integrated or integration
tested until “code
complete.”! # Defects!
• Release 2: ! Release 2!
• All teams produced an
increment of integrated, Time!
integration tested code
every Sprint. !
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
25
- 26. New
Baseline
Of
“Undone”
Work
Actual
Baseline
Perceived Work
+ Undone Work
Perceived
Baseline
Actual Work
Actual Work
Product Perceived
Backlog
Work
Undone Work
Time
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
26
- 27. Work Item Usual Rec. start Done
Requirements analysis 25 25 25
Design of architectural components (UI, System, Data 15 15 15
Design review 0 5 5
Design of tests (system, user acceptance, integration) 0 10 10
Design review 0 3 3
Design of documentation 0 2 2
Design Review 0 1 1
Refactoring of existing design 0 0 8
Design of unit tests for new code 0 3 3
Design of unit tests for code to be refactored 0 3 3
Writing new code 10 7 7
Writing refactored code 6 3 3
Code review (or pair programming) 0 4 4
Write functional tests 8 4 4
Write integration tests 0 4 4
Write documentation 4 4 4
Unit test code 0 2 2
Identify and rectify defects 0 2 2
Subsystem/team build 6 2 2
Identify and rectify defects 1 1 1
Unit test for subsystem/team code 0 2 2
Identify and rectify defects 0 2 2
System/integration build 1 1 1
Identify and rectify defects 0 2 2
System, functional tests 1 2 2
Identify and rectify defects 1 2 4
Integration tests 0 0 2
Identify and rectify defects 0 0 5
Performance tests 0 0 1
Identify and rectify defects 0 0 2
Security tests 0 0 1
Identify and rectify defects 0 0 2
Regression test 0 2 2
Identify and rectify defects 0 8 8
Documentation test 0 1 2
Identify and rectify defects 0 1 1
Total work expended requirement 78 118 148
Work remaining per requirement 65 30 0
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
27
- 28. SoEware
W/Low
Value
To
Developers
Core
FuncLonality
• Most
significant
new
Core funcLonality
builds
on
it;
Functionality
• Also
called
infrastructure
and
legacy
soEware;
• Is
fragile,
doesn’t
have
Product
New complete
test
harnesses,
Backlog
Functionality
and
few
people
sLll
know
how
to
or
are
willing
to
touch
it;
and,
• Requires
more
Lme
to
work
on;
velocity
working
on
it
is
Time
less
than
new
work.
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
28
- 29. Gradual
Impact
Of
Reduced
Quality
NPQ - Normal Product Quality
RPQ - Reduced Product Quality
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
29
- 30. Reduced
Velocity
Puts
OrganizaLon
In
Corner
Release 10
5 6 7
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
30
- 31. Exercise
• Your
CEO
comes
to
your
development
group.
She
tells
you
it
is
mandatory
to
deliver
three
new
pieces
of
funcLonality
within
three
Sprints.
Otherwise,
compeLtors
will
decimate
the
company.
• Planned
work
consists
of:
– FuncLon
1:
20
units
of
work,
15
new,
5
core
– FuncLon
2:
40
units
of
work,
25
new,
15
core
– FuncLon
3:
30
units
of
work,
20
new,
10
core
• Velocity
for
new
funcLonality
is
15
units
of
work
per
Sprint
per
team.
• Velocity
for
core
funcLonality
is
5
units
of
work
per
Sprint
total.
• You
need
a
release
with
all
three
funcLons
in
three
months.
• Can
do
you
do?
Can
you
save
the
company?
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
31
- 32. How
Does
Design-‐Dead
SoEware
Smell?
35
30
25
Maintenance
Cost
20
15
10
5
0
1
2
3
4
5
Release
29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
32
- 35. Filling
In
Scrum’s
Holes
Successful
SoAware
Development
PSM
PSPO
(Professional
(Professional
Scrum
Master)
Scrum
Product
Owner)
PSD
(Professional
PSTM
Scrum
Developer)
(Professional
Scrum
Team
Member)
29
March
2011
©
1993-‐2011
ADM,
All
Rights
Reserved
Slide
35
- 36. Professional
Scrum
Product
Owner
course
Agenda
• Teaches Product
• Basics
of
Agility
Owner how to achieve
• Value
Driven
Agility.
Development
• Complete course
• Product
Management
rewrite.
• Plan
a
Release
• For product managers,
• Managing
Requirements
program managers,
and development
• Planning
Releases
managers.
• Managing
Releases
• Assessments and
• Managing
Products
certification.
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
36
- 37. Next
Step
for
You!
When
Course
April
Professional
Scrum
Product
Owner
course
11-‐12
taught
by
ken
Schwaber
in
Amsterdam
April
6-‐7
Professional
Scrum
Master
course
taught
by
Ken
Schwaber
in
Brussels
Register
hvp://courses.scrum.org/
Visit
hvp://www.scrum.org/
29
March
2011
©
ADM
1993-‐2011
All
Rights
Reserved
v2.0
Slide
37
- 39. QuesLons?
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
29
March
2011
39
- 40. Thank
you!
Ken
Schwaber
• ken.schwaber@scrum.org
• www.scrum.org
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
29
March
2011
40