Kanban vs Scrum A practical guide Deep Lean, Stockholm May 19, 2009
Henrik Kniberg - Crisp AB Agile coach & Java guy Cofounder / CTO of Goyada (mobile services) 30 developers Lead architect at Ace Interactive (gaming) 20 developers Chief of development at Tain (gaming) 40 developers Agile coach at various companies
[email protected] +46 70 4925284
Introduction Purpose of this presentation: Clarify Kanban and Scrum by comparing them ...so you can figure out how these may come to use in your environment.
Henrik Kniberg
2
Split your organization
Scrum in a nutshell Split your product Large group spending a long time building a big thing Small team spending a little time building small thing ... but integrating regularly to see the whole
Optimize business value
Optimize process
$$$
Split time January
April
$
Henrik Kniberg
3
Kanban in a nutshell To do 5
Visualize the workflow Limit WIP (work in progress) Measure & optimize flow
Dev 3
H
Test 2
D G
Release 3
C
Done! A B
K
FLOW
Henrik Kniberg
4
Roots of Kanban (Toyota)
看板 Kan Ban ”Visual Card”
Buyer
Consume
Detach
Supplier
Receive
Ship
Allocate
Manufacture
The two pillars of the Toyota production system are just-in-time and automation with a human touch, or autonomation. The tool used to operate the system is kanban.
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”
Product Owner role
Pair programming Brownbag meetings
Henrik Kniberg
7
Prescriptive vs adaptive More prescriptive
More adaptive
RUP (120+) • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Architecture Reviewer Business Designer Business-Model Reviewer Business-Process Analyst Capsule Designer Change Control Manager Code Reviewer Configuration Manager Course Developer Database Designer Deployment Manager Design Reviewer Designer Graphic Artist Implementer Integrator Process Engineer Project Manager Project Reviewer Requirements Reviewer Requirements Specifier Software Architect Stakeholder System Administrator System Analyst Technical Writer Test Analyst Test Designer Test Manager Tester Tool Specialist User-Interface Designer Architectural analysis Assess Viability of architectural proof-of-concept Capsule design Class design Construct architectural proof-ofconcept Database design Describe distribution Describe the run-time architecture Design test packages and classes Develop design guidelines Develop programming guidelines Identify design elements Identify design mechanisms Incorporate design elements Prioritize use cases Review the architecture Review the design Structure the implementation model Subsystem design Use-case analysis Use-case design Analysis model Architectural proof-of-concept Bill of materials Business architecture document Business case Business glossary Business modeling guidelines Business object model Business rules Business use case
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Business use case realization Business use-case model Business vision Change request Configuration audit findings Configuration management plan Data model Deployment model Deployment plan Design guidelines Design model Development case Development-organization assessment End-user support mateirla Glossary Implementation model Installation artifacts Integration build plan Issues list Iteration assessment Iteration plan Manual styleguide Programming guidelines Quality assurance plan Reference architecture Release notes Requirements attributes Requirements management plan Review record Risk list Risk management plan Software architecture document Software development plan Software requirements specification Stakeholder requests Status assessment Supplementary business specification Supplementary specification Target organization assessment Test automation architecture Test cases Test environment configuration Test evaluation summary Test guidelines Test ideas list Test interface specification Test plan Test suite Tool guidelines Training materials Use case model Use case package Use-case modeling guidelines Use-case realization Use-case storyboard User-interface guidelines User-interface prototype Vision Work order Workload analysis model
Henrik Kniberg
XP (13) • • • • • • • • • • • • •
Whole team Coding standard TDD Collective ownership Customer tests Pair programming Refactoring Planning game Continuous integration Simple design Sustainable pace Metaphor Small releases
Scrum (9) • • • • • • • • •
Scrum Master Product Owner Team Sprint planning meeting Daily Scrum Sprint review Product backlogt Sprint backlog BUrndown chart
Kanban (3) • • •
Do Whatever (0)
Visualize the workflow Limit WIP Measure and optimize lead time
Do not develop an attachment to any one weapon or any one school of fighting Miyamoto Musashi 17th century samurai
8
Scrum prescribes roles
PO
Henrik Kniberg
SM
9
Scrum prescribes iterations Scrum team Kanban team 1
week 1
week 3
week 4
Sprint 1
Plan & commit
Kanban team 2
week 2
week 5
week 6
week 7
week 8
Sprint 2
Demo (release?)
Retrospective
week 1
week 2
week 3
week 4
week 5
week 6
week 7
week 8
week 1
week 2
week 3
week 4
week 5
week 6
week 7
week 8
Retrospectives (4w) Planning cadence (2w) Release cadence (1w)
Kanban team 3 Retrospectives (4w) Planning (on demand) Release (on demand)
Henrik Kniberg
10
Both limit WIP, but in different ways Kanban board
Scrum board To do
Ongoing Done :o)
To do
Ongoing Done :o) 2 A
A B
B C
C
D
D FLOW
WIP limited per unit of time (iteration)
Henrik Kniberg
FLOW
WIP limited per workflow state
11
Both are empirical
Capacity
Lead time
Quality
Predictability
(aka velocity)
(aka cycle time)
(defect rate, etc)
(SLA fulfillment, etc)
Kanban is more configurable
Many small teams Low WIP limits Few workflow states
Few large teams
Many workflow states Long iterations
Little planning
Lots of planning
Henrik Kniberg
Oh no, more complicated!
High WIP limits
Short iterations
.... etc ...
Great! More options!
.... etc ...
12
Example: Experimenting with WIP limits Monday, Week 1 To do Ongoing
1
Done :o)
To do Ongoing
8
A
B
C D E F
Monday, Week 2
E F G
ZZZZzzzzzz
Monday, Week 5 4
N O P
L M
Done :o)
To do Ongoing
8
A B
H I
D E F
Done :o)
A B C
To do Ongoing
8
L
E F
Done :o)
A B C
G I
We’re idle & bored! Let’s increase WIP limit to 8!
To do Ongoing
C D
Monday, Week 4
Monday, Week 3
Done :o)
Problem with integration server. Can’t finish D & E! We’ll work on F & G instead!
J K Oops. WIP limit reached. Now we HAVE to stop and fix the integration server!
Let’s reduce WIP limit to 4, so we react earlier next time!
J K
Henrik Kniberg
13
I’d like to have E!
Scrum doesn’t allow change in mid-iteration
PO Wait until a To Do slot becomes available! Or swap out C or D!
Wait until next sprint!
Kanban
Scrum To do
Ongoing Done :o)
To do 2
Ongoing Done :o) 2
C
A
C
A
D
B
D
B
FLOW
Henrik Kniberg
FLOW
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 Scrum
Kanban – example 1
Kanban – example 2
Specialist Cross-functional team
Henrik Kniberg
Cross-functional team
Cross-functional team
Specialist team
16
Scrum backlog items must fit in a sprint Scrum
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Kanban Long running task WIP limit = 3
Henrik Kniberg
Long running task
17
In Scrum, estimation and velocity is prescribed
V= 8
1
V= 7
2 2
Sprint 1
Henrik Kniberg
2 3
1 Sprint 2
V= 9
1 3
1
1 2
2 2
1
Likely velocity: 8 per sprint (sustainable pace?)
Sprint 3
18
Both allow working on multiple products simultaneously Kanban example 1
Scrum example 1 Green Product
Green team
Scrum example 2 All products
Cross-product team
Henrik Kniberg
Color-coded tasks Yellow Product
Yellow team
Scrum example 3 All products
Kanban example 2 Color-coded swimlanes
Cross-product team
19
1.
Both are Lean and Agile
2. 3. 4. 5. 6. 7. 8.
1. 2. 3. 4.
Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
9. 10. 11. 12. 13. 14.
Base your management decisions on a Long-Term Philosophy, Even at the Expense of Short-Term Financial Goals Create Continuous Process Flow to Bring Problems to the Surface Use Pull Systems to Avoid Overproduction Level Out the Workload (Heijunka) Build a Culture of Stopping to Fix Problems, to Get Quality Right the First Time Standardized Tasks are the Foundation for Continuous Improvement and Employee Empowerment Use Visual Controls So No Problems are Hidden Use Only Reliable, Thoroughly Tested Technology That Serves Your People and Processes Grow Leaders Who Thoroughly Understand the Work, Live the Philosophy, and Teach It to Others Develop Exceptional People and Teams Who Follow Your Company’s Philosophy Respect Your Extended Network of Partners and Suppliers by Challenging Them and Helping Them Improve Go and See for Yourself to Thoroughly Understand the Situation (Genchi Genbutsu) Make Decisions Slowly by Concensus, Thoroughly Considering All Options; Implement Decisions Rapidly Become a Learning Organization Through Relentless Reflection (Hansei) and Continuous Improvement (Kaizen)
Lean Quality – Cost – Lead Time People Just in Time
Kaizen
Stop the Line
Waste reduction
Henrik Kniberg
Operational stability
20
Minor difference: Scrum prescribes a prioritized product backlog Scrum: Product backlog must exist Changes to product backlog take effect next sprint (not current sprint) Product backlog must be sorted by business value
... but many teams combine these approaches
Henrik Kniberg
Kanban: Product backlog is optional Changes to product backlog take effect as soon as capacity becomes available Any prioritization scheme can be used. For example: Take any item Always take the top item Always take the oldest item 20% on maintainance items, 80% on new features Split capacity evenly between product A and product B Always take red items first
21
Minor difference: Scrum prescribes daily meetings
... but many Kanban teams do that anyway.
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 backlog
Sprint backlog
Committed Ongoing Done :o)
E E F F G HG
A B
I J H L K M
C D
Kanban
F H
Dev
Selected
Backlog
2
G
I J L K M
Henrik Kniberg
In production :o)
3 Ongoing
D
B
E
C
Done
A
X Q
R
24
Scenario 1 – one piece flow
Selected
Backlog A
2
Dev In production :o)
3 Ongoing
Done
B
G C F H J M
D I
L K
Henrik Kniberg
E
25
Scenario 1 – one piece flow
Selected
Backlog
2
Ongoing
Done
B
C F H
M
In production :o)
3
A
G
J
Dev
D I
L K
Henrik Kniberg
E
26
Scenario 1 – one piece flow
Backlog
2
Ongoing
Done
B
C F H
M
In production :o)
3
A
G
J
Dev
Selected
D I
L K
Henrik Kniberg
E
27
Scenario 1 – one piece flow
Dev
Selected
Backlog
2
Ongoing
C
G
D
In production :o)
3 Done A B
F H J M
I L K
Henrik Kniberg
E
28
Scenario 1 – one piece flow
Dev
Selected
Backlog
2
In production :o)
3 Ongoing
Done
C
G D
A B
F H J M
I L K
Henrik Kniberg
E
29
Scenario 1 – one piece flow
Backlog
2 F
G
E
H J M
Dev
Selected
In production :o)
3 Ongoing D
Done C
A B
I L K
Henrik Kniberg
30
Scenario 2 – Deployment problem
Selected
Backlog A
2
Dev In production :o)
3 Ongoing
Done
B
G C F H J M
D I
L K
Henrik Kniberg
E
31
Scenario 2 – Deployment problem
Selected
Backlog
2
Ongoing
Done
B
C F H
M
In production :o)
3
A
G
J
Dev
D I
L K
Henrik Kniberg
E
32
Scenario 2 – Deployment problem
Dev
Selected
Backlog
2
G
In production :o)
3 Ongoing
C
A
D
B
Done
F H J M
I L K
Henrik Kniberg
E
33
Scenario 2 – Deployment problem
Dev
Selected
Backlog
2
Ongoing C
G D
In production :o)
3 Done A
B
F H J M
I L K
Henrik Kniberg
E
34
Scenario 2 – Deployment problem
Dev
Selected
Backlog
2
G D
In production :o)
3 Ongoing
Done
C
A
!?
B
F H J M
I L K
Henrik Kniberg
E
35
Scenario 2 – Deployment problem
Backlog
2
F H
M
In production :o)
3 Ongoing
!?
G
J
Dev
Selected
Done A
D
B
E
C
I L K
Henrik Kniberg
36
Scenario 2 – Deployment problem
Backlog
Selected 2
F H
M
In production :o)
3 Ongoing
Done A
G
J
Dev
D
B
E
C
I L K
Henrik Kniberg
37
Scenario 2 – Deployment problem
Backlog
Selected 2
Dev In production :o)
3 Ongoing
Done A
G D F H J M
E
B C
I L K
Henrik Kniberg
38
Scenario 2 – Deployment problem
Backlog
In production :o)
3 Ongoing
Done
H
A B
E
F
M
2
D
G
J
Dev
Selected
C I
L K
Henrik Kniberg
39
Kanban vs Scrum
www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf
Summary Similarities Both are Lean and Agile Both based on pull scheduling Both limit WIP Both use transparency to drive process improvement Both focus on delivering releasable software early and often Both are based on self-organizing teams Both require breaking the work into pieces In both cases the release plan is continuously optimized based on empirical data (velocity / lead time)
Henrik Kniberg
Differences Scrum
Kanban
Timeboxed iterations prescribed.
Timeboxed iterations optional.
Team commits to a specific amount of work for this iteration. Uses Velocity as default metric for planning and process improvement. Cross-functional teams prescribed. Items broken down so they can be completed within 1 sprint. Burndown chart prescribed
Commitment optional.
WIP limited indirectly (per sprint) Estimation prescribed Cannot add items to ongoing iteration. A sprint backlog is owned by one specific team Prescribes 3 roles (PO/SM/Team) A Scrum board is reset between each sprint Prescribes a prioritized product backlog
Uses Lead time as default metric for planning and process improvement. Cross-functional teams optional. Specialist teams allowed. No particular item size is prescribed. No particular type of diagram is prescribed WIP limited directly (per workflow state) Estimation optional Can add new items whenever capacity is available A kanban board may be shared by multiple teams or individuals Doesn’t prescribe any roles A kanban board is persistent Prioritization is optional.40
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
