Path to agility, Ken Schwaber

Scrum!
for 
Paris User Group!

1

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

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

What
are
some
speciﬁc
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

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

unﬁlled
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

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

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

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

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

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

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

The
ﬁrst
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

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

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

•  ﬂoor
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

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

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

The
ﬁrst
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

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
deﬁned
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

Green
Field
SoEware

Product
Backlog Velocity (done work over time)
(work)

Time

29
March
2011
©
ADM
1983-‐2010
All
Rights
Reserved
v2.0
19

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
deﬁniLon
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

Exercise
(Cont.)

Did
your
deﬁniLon
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

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

Case
Study:
TransCanada
Pipelines

•  After three Sprints, Product Owner was delighted.
She wanted us to continue, but she wanted us to
implement the ﬁrst 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

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 ﬁve+ month stabilization was required prior to release.!
“Inadequate performance” was a bug logged in the ﬁrst 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

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

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

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
Unit test for subsystem/team code 0 2 2
System/integration build 1 1 1
System, functional tests 1 2 2
Integration tests 0 0 2
Performance tests 0 0 1
Security tests 0 0 1
Regression test 0 2 2
Documentation test 0 1 2

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

SoEware
W/Low
Value
To
Developers

Core
FuncLonality

•  Most
signiﬁcant
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

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

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

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

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

Path to agility, Ken Schwaber

Recommended

Recommended

More Related Content

What's hot

What's hot (19)

Similar to Path to agility, Ken Schwaber

Similar to Path to agility, Ken Schwaber (20)

More from Xavier Warzee

More from Xavier Warzee (20)

Recently uploaded

Recently uploaded (20)

Path to agility, Ken Schwaber