This document summarizes a presentation about applying lean and agile principles to a large government project in Sweden called PUST. It describes how the project team used techniques like slicing work into small customer-focused stories, daily stand-ups, iterative planning and releases, continuous improvement retrospectives, and tracking metrics to successfully deliver the project on time and on budget while continuously improving their process.

1. Lean from the Trenches
Oct 6, 2012
Agile Eastern Europe, Kiev
Henrik Kniberg
Agile/Lean coach
www.crisp.se

2. Henrik Kniberg 2

3. 3
Henrik Kniberg

4. 4
Henrik Kniberg

5. Lean principles
Kanban
XP
Scrum
Henrik Kniberg 5

6. <dislaimer>
No solutions.
Only examples.
</disclaimer>
Henrik Kniberg 6

7. Once upon a
time…
7
7

8. PUST – Polisens Utrednings STöd
2011 2010
Henrik Kniberg 8

9. Timeline
First pilot Nationwide
Project launch
1.0 1.1 1.2 1.3 1.4 1.5
Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2
2009 2010 2011
10 people
30 people 60+ people
Henrik Kniberg 9

10. Slicing the elephant
Region
Östergötland,
Uppsala, etc
1.0
Crime types 1.1
1.3 1.4
(weapon,
drunk driving, 1.2
shoplifting,
etc) 1.5
PUST
Integrations
Henrik Kniberg 10

11. User involvement
Acceptance test Pilot users
user group
”Customer”
Onsite
PUST Project user
Henrik Kniberg 11

12. Team structure &
”Daily cocktail
party”
12
12

13. Team structure - before
Requirements 3 Test
analyst Development team
team teams
! !
#% #%
!? !?
Henrik Kniberg 13

14. Improved team structure
Requirements 3
System test
analyst Feature
team
team teams
Henrik Kniberg 14

15. ”Daily cocktail party” 9:15 – 10:15
Henrik Kniberg 15

16. 10:00 – 10:15
Project sync
9:45 – 10:00 9:45 – 10:00
Requirements Dev sync
Test sync
sync
9:30 – 9:45 9:30 – 9:45 9:15 – 9:30
Feature team 1 Feature team 2 Feature team 3
16
Henrik Kniberg

17. The project board
17
17

18. Next 10 User
Ideas Features Development System
features acceptance Production
test
test
FLOW
Henrik Kniberg 18

19. Henrik Kniberg 19

20. Cadences
week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Retrospectives (2w)
Planning (2w)
Demo & systest (continuous)
Release (2m)
20

21. 21

22. Henrik Kniberg 22

23. Impediments & escalation
Feature General
blocked impediments
Can’t
2011-03-01!
Police car = As police!t!!
asdfasdfasdf
tes r!
ing fo der!
I need tocode rea
Wait scan!
urgent
(patch)
bar
So that JMmr! ch 12!
!i a
Henrik Kniberg 23

24. Scaling the boards
24 24

25. Feature swimlanes
Next 10 Dev Ready for Sys test
features in progress sys test progress
Henrik Kniberg 25

26. Next 10 Dev Ready for
features in progress sys test
Dev Team 1 Dev Team 2 Dev Team 3
26
Henrik Kniberg 26

27. Definition of
”ready for
development”
Definition of
”ready for
system test”
Henrik Kniberg 27

28. Henrik Henrik
Kniberg Kniberg 28 28

29. How we handle
tech stories
29
29

30. Tech stories
Next 10
features
Ready for
Development
Next 5 tech
stories
Henrik Kniberg 30

31. Example: the 7 meter class
Henrik Kniberg 31

32. ”Oh no, bottleneck
in System Test!
FLOW
Henrik Kniberg 32

33. Question of the week:
How can we best
contribute to system test
today?
Bottleneck
”Let’s stop
building new
features”
”... and focus on
test automation!”
Henrik Kniberg 33

34. Everyone
doing tech
stories
Henrik Kniberg 34

35. How we handle
bugs
35
35

36. Release
Before:
Test at end Test Fix %&@#!
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Now: Release
Test continuously
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Test Fix
Test at end:
%&@#!
Test continuously:
Test Fix Time
saved!
Henrik Kniberg 36

37. Bug fixing process
Bug found!
Yes Write sticky-note,
Blocker? find developer,
fix now!
No
More important Yes Replace one of
than any of the the other
current top 30? top 30 bugs
with this one
No
Ignore
it
Don’t log it.
Fix it NOW!
Henrik Kniberg 37

38. Three input queues
Next 10
features
Next 5 tech
stories
Next 5 lower
priority bugs
Henrik Kniberg 38

39. Recurring bugs
Henrik Kniberg 39

40. How we
continuously
improve the
process
40
40

41. Retrospectives every
1-2 weeks
Henrik Kniberg 41

42. Too much, too fast!
Henrik Kniberg 42

43. Limiting the rate of change
”A4”
improvement
proposal
”A4”
improvement
proposal
”A4”
improvement
proposal
”A4”
improvement
proposal
Henrik Kniberg 43

44. Proposal:
More
Customer-­‐Valued
Stories
Why?
What
Problem
Are
We
Trying
to
Solve?
DescripAon
/
FAQ
A
story
that
goes
into
development
must:
• Hard
to
get
an
overview
of
the
project
board
1. Be
size
S
or
M
from
customer
perspec7ve,
many
stories
are
2. Be
as
customer
valuable
as
possible,
as
long
as
we
don’t
break
the
size
rule.
so
small
that
they
can’t
be
delivered.
The
requirements
team
ensures
that
each
card
under
”Ready
for
Who
Is
Affected
By
The
Change?
Development”
is
a
customer-­‐valued
story
(regardless
of
size).
• Requirements,
development,
and
test
teams.
However,
before
it
enters
development
it
must
be
S
or
M.
Ques7on:
What
happens
if
the
story
is
L,
and
must
be
delivered
as
What
Are
the
Change
ImplementaAon
Steps?
a
whole
before
it
is
valuable
to
the
customer?
• Update
Defini7on
of
Done
for
”Ready
for
• Break
it
down
to
smaller
stories
(new
cards)
which
are
size
M,
but
with
highest
possible
customer
value
per
story.
Development”,
add
”the
story
is
valuable
to
• Visually
group
these
stories
by
wri7ng
the
name
of
the
higher
the
customer”.
level
feature
in
big
blue
leSers
at
the
top
of
each
card.
• Go
through
the
board
&
iden7fy
stories
that
are
too
small
to
be
valuable.
Combine
these
into
bigger
stories
(as
long
as
they
don’t
exceed
Medium).
Example:
CONFISCATION
Register
Confiscation
M
Confiscation CONFISCATION
L Remove
Confiscation
Henrik Kniberg S 44

45. Limiting the rate of change
”A4”
improvement
proposal
”A4”
improvement
proposal
”A4”
improvement
proposal
”A4”
improvement
proposal
Henrik Kniberg 45

46. How we capture
and use process
metrics
46
46

47. Process metrics
" Velocity = feature per week
" Throughput time = weeks per feature
47

48. Velocity – stories per week
Ready for
acceptance test
(this week so far)
Ready for
acceptance test
(previous weeks)
Velocity per week
Henrik Kniberg 48

49. Velocity-based release planning
All of these will
be done
# of
features Week
delivered to Some of these
acceptance will be done,
test but not all
None of these
will be done 49
Henrik Kniberg 49

50. Henrik Kniberg 50

51. Bed
Total time!
work
Play time!
Timeline
Henrik Kniberg (5 minute 51
intervals)

52. Henrik Kniberg 52

53. Velocity improvement
Q2
6.5 features per
Q1 week
# of 3 features
features per week
delivered to
acceptance
test
Week
Henrik Kniberg 53

54. Throughput time – weeks per feature
Ready for
Next 10 acceptance
Throughput time (elapsed days)
features test
Henrik Kniberg 54

55. Elapsed
days
Feature
Henrik Kniberg 55

56. Throughput time improvement
Q1
6-14 weeks
per feature Q2
3-6 weeks
per feature
Elapsed
days
Henrik Kniberg 56

57. Surprising insight
Average throughput time
Small:
31
days
Medium:
37
days
Elapsed ”Small” & ”Medium” Large:
59
days
days
features take roughly same
amount of time
Feature
Henrik Kniberg 57

58. How we track the
high level goal
58
58

59. High level
goal
Milestone
Henrik Kniberg 59

60. Death March Detection
using gut feel
Do you believe the
current goal is
achievable?
5 = certainly
4 = probably
3 = barely
2 = probably not
1 = forget it
Henrik Kniberg 60

61. Henrik Kniberg 61

62. Wrapup
62
62

63. Setting the project up Incremental delivery
for success
Co-location
Customer involvement
63

64. Creating a culture of
continuous improvement
Clarity
Communication
Data
Henrik Kniberg 64

65. Perfection is a direction, not a place
The important thing is not
how you work.
The important thing is
how you improve the way you work!
Henrik Kniberg 65