A practical guide
Deep Lean, Stockholm
May 19, 2009
henrik.kniberg@crisp.se
+46 70 4925284
Introduction
Henrik Kniberg 2
Split your organization
Scrum in a nutshell
Split your product
$$$
Split time
January April
Henrik Kniberg 3
Kanban in a nutshell
To do Dev Test Release Done!
5 3 2 3
Henrik Kniberg 4
看板
Roots of Kanban Kan Ban
”Visual Card”
(Toyota)
Buyer Supplier
Taiichi Ohno
Father of the Toyota Production System
Henrik Kniberg 5
Kanban in software development
Henrik Kniberg 6
Kanban and Scrum are both process tools
Physical tools Process tools
a.k.a. ”organizational patterns”
Pair programming
Brownbag meetings
Henrik Kniberg 7
Prescriptive vs adaptive
•
Assess Viability of architectural
proof-of-concept
Capsule design
•
•
Software architecture
document
Software development
or any one school of fighting
• Class design plan
• Construct architectural proof-of- • Software requirements
•
•
concept
Database design
Describe distribution
•
•
specification
Stakeholder requests
Status assessment
Miyamoto Musashi
•
•
Describe the run-time architecture
Design test packages and classes
• Supplementary business
specification 17th century samurai
• Develop design guidelines • Supplementary specification
• Develop programming guidelines • Target organization assessment
• Identify design elements • Test automation architecture
• Identify design mechanisms • Test cases
• Incorporate design elements • Test environment configuration
• Prioritize use cases • Test evaluation summary
• Review the architecture • Test guidelines
• Review the design • Test ideas list
• Structure the implementation • Test interface specification
model • Test plan
• Subsystem design • Test suite
• Use-case analysis • Tool guidelines
• Use-case design • Training materials
• Analysis model • Use case model
• Architectural proof-of-concept • Use case package
• Bill of materials • Use-case modeling guidelines
• Business architecture document • Use-case realization
• Business case • Use-case storyboard
• Business glossary • User-interface guidelines
8
• Business modeling guidelines • User-interface prototype
Henrik Kniberg
•
•
•
Business object model
Business rules
Business use case
•
•
•
Vision
Work order
Workload analysis model
Scrum prescribes roles
PO
SM
Henrik Kniberg 9
Scrum prescribes iterations
week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Scrum team
Sprint 1 Sprint 2
Kanban team 1
Plan & commit Demo
Retrospective
(release?)
Kanban team 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Retrospectives (4w)
Kanban team 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Retrospectives (4w)
Henrik Kniberg 10
Both limit WIP, but in different ways
Scrum board Kanban board
FLOW FLOW
WIP limited per unit of time WIP limited per workflow state
(iteration)
Henrik Kniberg 11
Both are empirical
Many small teams Few large teams Great! More options! Oh no, more complicated!
Henrik Kniberg 12
Example: Experimenting with WIP limits
Monday, Week 1 Monday, Week 2 Monday, Week 3 Monday, Week 4
To do Ongoing Done :o) To do Ongoing Done :o) To do Ongoing To do Ongoing
Done :o) Done :o)
1 8 8 8
C B A C A D A A
B H B B
D E D E E
E F I F C L C
F
F G
G
ZZZZzzzzzz
I
We’re idle & bored! Problem with J
Let’s increase WIP integration server. K
limit to 8! Can’t finish D & E!
We’ll work on F & G
instead! Oops. WIP limit
reached. Now we
HAVE to stop and Let’s reduce WIP
Monday, Week 5 fix the integration limit to 4, so we
To do Ongoing server! react earlier next
Done :o)
4 time!
N L J
O M K
P
Henrik Kniberg 13
I’d like to have E!
Scrum Kanban
D B D B
FLOW FLOW
Henrik Kniberg 14
Scrum board is reset between each
iteration
Scrum
First day of sprint Mid-sprint Last day of sprint
Kanban
Any day
Henrik Kniberg 15
Scrum prescribes cross-functional teams
Specialist Specialist
Cross-functional
Cross-functional team
Cross-functional team
team team
Henrik Kniberg 16
Scrum backlog items must fit in a sprint
Scrum
Kanban
Henrik Kniberg 17
In Scrum, estimation and velocity is
prescribed
V= 8 V= 7 V= 9
1 2 2 1 1 2
Likely velocity: 8 per sprint
2 3 1 3 1 2 2 1 (sustainable pace?)
Henrik Kniberg 18
Both allow working on multiple products
simultaneously
Scrum example 1 Kanban example 1
Color-coded tasks
Green Product Yellow Product
Green team Yellow team
Henrik Kniberg 19
1. Base your management decisions on a Long-Term Philosophy, Even at the
Expense of Short-Term Financial Goals
2. Create Continuous Process Flow to Bring Problems to the Surface
Lean
Quality – Cost – Lead Time
People
Waste
reduction
Henrik Kniberg Operational stability 20
Minor difference:
Scrum prescribes a prioritized product backlog
Scrum: Kanban:
Product backlog must Product backlog is optional
exist Changes to product backlog
Changes to product take effect as soon as
backlog take effect next capacity becomes available
sprint (not current sprint) Any prioritization scheme can
Product backlog must be be used. For example:
sorted by business value Take any item
Always take the top item
Always take the oldest item
20% on maintainance items,
80% on new features
... but many teams combine these approaches
Split capacity evenly between
product A and product B
Always take red items first
Henrik Kniberg 21
Minor difference:
Scrum prescribes daily meetings
Henrik Kniberg 22
Minor difference:
In Scrum, burndown charts are prescribed
No specific types of diagrams
prescribed in Kanban. Teams
use whatever they need.
Henrik Kniberg 23
Example: Scrum board vs Kanban board
Scrum
Product Sprint backlog
backlog Committed Ongoing Done :o)
E
E
F A
F
G B
HG I C
J H
L
K D
M
Kanban
Dev
Backlog Selected 3 In production :o)
2 Ongoing Done
D B A X
F R
G E C
H Q
I
J L
M K
Henrik Kniberg 24
Scenario 1 – one piece flow
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
A
B
G
C
F
D
H
I
J L E
M K
Henrik Kniberg 25
Scenario 1 – one piece flow
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Henrik Kniberg 26
Scenario 1 – one piece flow
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Henrik Kniberg 27
Scenario 1 – one piece flow
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
C A
G
D B
H
I
J L E
M K
Henrik Kniberg 28
Scenario 1 – one piece flow
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
C A
G
D B
H
I
J L E
M K
Henrik Kniberg 29
Scenario 1 – one piece flow
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
F D C A
G
B
E
H
I
J L
M K
Henrik Kniberg 30
Scenario 2 – Deployment problem
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
A
B
G
C
F
D
H
I
J L E
M K
Henrik Kniberg 31
Scenario 2 – Deployment problem
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Henrik Kniberg 32
Scenario 2 – Deployment problem
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
C A
G
D B
H
I
J L E
M K
Henrik Kniberg 33
Scenario 2 – Deployment problem
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
C A
G
D B
H
I
J L E
M K
Henrik Kniberg 34
Scenario 2 – Deployment problem
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
C A
G
D
!? B
H
I
J L E
M K
Henrik Kniberg 35
Scenario 2 – Deployment problem
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
G !? A
D B
F
E C
H
I
J L
M K
Henrik Kniberg 36
Scenario 2 – Deployment problem
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
A
G
D B
F
E C
H
I
J L
M K
Henrik Kniberg 37
Scenario 2 – Deployment problem
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
A
G
D B
F
E C
H
I
J L
M K
Henrik Kniberg 38
Scenario 2 – Deployment problem
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
D A
G
B
E
F
C
H
I
J L
M K
Henrik Kniberg 39
Kanban vs Scrum www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf
Summary
Similarities Differences
Both are Lean and Agile Scrum Kanban
Both based on pull scheduling Timeboxed iterations prescribed. Timeboxed iterations optional.
Both limit WIP
Team commits to a specific amount Commitment optional.
Both use transparency to drive process
of work for this iteration.
improvement Uses Velocity as default metric for Uses Lead time as default metric for
Both focus on delivering releasable planning and process improvement. planning and process improvement.
software early and often Cross-functional teams Cross-functional teams optional.
Both are based on self-organizing teams prescribed. Specialist teams allowed.
Both require breaking the work into Items broken down so they can be No particular item size is prescribed.
pieces completed within 1 sprint.
Burndown chart prescribed No particular type of diagram is
In both cases the release plan is
prescribed
continuously optimized based on
WIP limited indirectly (per sprint) WIP limited directly (per workflow
empirical data (velocity / lead time)
state)
Estimation prescribed Estimation optional
Cannot add items to ongoing Can add new items whenever
iteration. capacity is available
A sprint backlog is owned by one A kanban board may be shared
specific team by multiple teams or individuals
Prescribes 3 roles (PO/SM/Team) Doesn’t prescribe any roles
A Scrum board is reset between A kanban board is persistent
each sprint
Henrik Kniberg Prescribes a prioritized product Prioritization is optional.40
backlog
Most importantly:
Start with retrospectives!
Evolve the right process
for your context.
Don’t worry about
getting it right from the
start.
Expand your toolkit.
Experiment!
Henrik Kniberg 41