henrik kniberg: lean from the trenches keynote @ agileee
TRANSCRIPT
Lean from the Trenches Oct 6, 2012
Agile Eastern Europe, Kiev
Henrik Kniberg Agile/Lean coach
www.crisp.se
2 Henrik Kniberg 2
3 Henrik Kniberg
3
4 Henrik Kniberg
4
5 Henrik Kniberg 5
Kanban
Scrum
XP
Lean principles
6
<dislaimer>
No solutions. Only examples.
</disclaimer>
Henrik Kniberg 6
7
Once upon a time…
7
8
PUST – Polisens Utrednings STöd
Henrik Kniberg 8
2011 2010
9 Henrik Kniberg 9
Timeline
Q3 Q4 Q3 Q4 Q1 Q2 Q1 Q2
2009 2010 2011
1.1 1.2 1.3 1.5
Project launch
10 people
30 people 60+ people
1.0
First pilot
1.4
Nationwide
10
Slicing the elephant
Henrik Kniberg 10
PUST
1.0
1.2
1.3 1.4
1.5
Region Östergötland, Uppsala, etc
Crime types (weapon, drunk driving, shoplifting, etc)
Integrations
1.1
11 Henrik Kniberg 11
PUST Project
”Customer”
Acceptance test user group
Onsite user
Pilot users
User involvement
12
Team structure & ”Daily cocktail party”
12
13
Team structure - before
Henrik Kniberg 13
3 Development
teams
Test team
Requirements analyst team
?
% #
!
!
?
% #
!
!
14
Improved team structure
Henrik Kniberg 14
3 Feature teams
System test team
Requirements analyst team
15 Henrik Kniberg 15
”Daily cocktail party” 9:15 – 10:15
16 Henrik Kniberg
16
Feature team 1 Feature team 2 Feature team 3
9:30 – 9:45 9:15 – 9:30 9:30 – 9:45
9:45 – 10:00
Test sync
Requirements sync
Dev sync
9:45 – 10:00
Project sync
10:00 – 10:15
17
The project board
17
18 Henrik Kniberg 18
Next 10 features Ideas Features Development System
test
User acceptance
test
FLOW
Production
19 Henrik Kniberg 19
20
Planning (2w)
week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Retrospectives (2w)
Release (2m)
Demo & systest (continuous)
Cadences
21
22 Henrik Kniberg 22
23
Impediments & escalation
Henrik Kniberg 23
Feature blocked
General impediments
asdfasdfasdf As police!I need to scan!So that !
Can’t test!!Waiting fo
r!
barcode reader!
Jim!March 12!
2011-03-01!
Police car = urgent (patch)
24
Scaling the boards
24
25 Henrik Kniberg 25
Next 10 features
Ready for sys test
Dev in progress
Sys test progress
Feature swimlanes
26
Henrik Kniberg 26
Dev Team 1 Dev Team 2 Dev Team 3
Next 10 features
Dev in progress
Ready for sys test
27 Henrik Kniberg 27
Definition of ”ready for
development”
Definition of ”ready for
system test”
28 Henrik Kniberg 28 Henrik Kniberg 28
29
How we handle tech stories
29
30
Tech stories
Henrik Kniberg 30
Next 5 tech stories
Next 10 features
Ready for Development
31
Example: the 7 meter class
Henrik Kniberg 31
32 Henrik Kniberg 32
”Oh no, bottleneck in System Test!
FLOW
33 Henrik Kniberg 33
Bottleneck
”Let’s stop building new
features”
”... and focus on test automation!”
Question of the week: How can we best
contribute to system test today?
34 Henrik Kniberg 34
Everyone doing tech
stories
35
How we handle bugs
35
36 Henrik Kniberg 36
Test Fix %&@#!
Release
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Release
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8
Test at end:
Test
%&@#!
Fix
Fix Time saved!
Test
Test continuously:
Before: Test at end
Now: Test continuously
37
Bug fixing process
Henrik Kniberg 37
Bug found!
More important than any of the current top 30?
No
Write sticky-note, find developer,
fix now!
Yes
Replace one of the other
top 30 bugs with this one
Yes
Ignore it
No
Don’t log it. Fix it NOW!
Blocker?
38
Three input queues
Henrik Kniberg 38
Next 5 tech stories
Next 10 features
Next 5 lower priority bugs
39 Henrik Kniberg 39
Recurring bugs
40
How we continuously improve the process
40
41
Retrospectives every 1-2 weeks
Henrik Kniberg 41
42
Too much, too fast!
Henrik Kniberg 42
43
Limiting the rate of change
Henrik Kniberg 43
”A4” improvement proposal
”A4” improvement proposal
”A4” improvement proposal
”A4” improvement proposal
44 Henrik Kniberg 44
Proposal: More Customer-‐Valued Stories Why? What Problem Are We Trying to Solve? • Hard to get an overview of the project board
from customer perspec7ve, many stories are so small that they can’t be delivered.
DescripAon / FAQ A story that goes into development must: 1. Be size S or M 2. Be as customer valuable as possible, as long as we don’t
break the size rule.
The requirements team ensures that each card under ”Ready for Development” is a customer-‐valued story (regardless of size). However, before it enters development it must be S or M. Ques7on: What happens if the story is L, and must be delivered as a whole before it is valuable to the customer? • Break it down to smaller stories (new cards) which are size M,
but with highest possible customer value per story. • Visually group these stories by wri7ng the name of the higher
level feature in big blue leSers at the top of each card.
Who Is Affected By The Change? • Requirements, development, and test teams.
What Are the Change ImplementaAon Steps? • Update Defini7on of Done for ”Ready for
Development”, add ”the story is valuable to the customer”.
• 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).
Remove Confiscation
CONFISCATION
S
Confiscation L
Example: Register
Confiscation
CONFISCATION
M
45
Limiting the rate of change
Henrik Kniberg 45
”A4” improvement proposal
”A4” improvement proposal
”A4” improvement proposal
”A4” improvement proposal
46
How we capture and use process metrics
46
47
Process metrics
" Velocity = feature per week " Throughput time = weeks per feature
48 Henrik Kniberg 48
Ready for acceptance test
(this week so far)
Ready for acceptance test
(previous weeks)
Velocity per week
Velocity – stories per week
49 Henrik Kniberg 49
49
# of features delivered to acceptance test
Week
Velocity-based release planning All of these will
be done
Some of these will be done, but not all
None of these will be done
50 Henrik Kniberg 50
51 Henrik Kniberg 51
Bed time!
Timeline (5 minute intervals)
Total work
Play time!
52 Henrik Kniberg 52
53
Velocity improvement
Henrik Kniberg 53
Q1 3 features per week
Q2 6.5 features per
week
# of features delivered to acceptance test
Week
54
Throughput time – weeks per feature
Henrik Kniberg 54
Next 10 features
Ready for acceptance
test Throughput time (elapsed days)
55 Henrik Kniberg 55
Elapsed days
Feature
56
Throughput time improvement
Henrik Kniberg 56
Q1 6-14 weeks per feature Q2
3-6 weeks per feature
Elapsed days
57
Surprising insight
Henrik Kniberg 57
”Small” & ”Medium” features take roughly same
amount of time
Large: 59 days
Medium: 37 days
Small: 31 days Average throughput time
Elapsed days
Feature
58
How we track the high level goal
58
59 Henrik Kniberg 59
High level goal
Milestone
60
Death March Detection using gut feel
Henrik Kniberg 60
5 = certainly 4 = probably 3 = barely 2 = probably not 1 = forget it
Do you believe the current goal is achievable?
61 Henrik Kniberg 61
62
Wrapup
62
63
Incremental delivery Setting the project up for success Co-location
Customer involvement
64
Creating a culture of continuous improvement
Henrik Kniberg 64
Communication
Data
Clarity
65
Perfection is a direction, not a place
Henrik Kniberg
The important thing is not how you work.
The important thing is how you improve the way you work!