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

henrik.kniberg@crisp.se
+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 process
Optimize business value

$$$

Split time
January April

Henrik Kniberg 3
Kanban in a nutshell
To do Dev Test Release Done!
5 3 2 3

Visualize the workflow H D C

A
G
B
Limit WIP (work in progress)
K

Measure & optimize flow

FLOW

Henrik Kniberg 4
 看板
Roots of Kanban Kan Ban
”Visual Card”
(Toyota)
Buyer Supplier

Consume Detach 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 XP Scrum Kanban Do Whatever

(120+) (13) (9) (3) (0)
• Architecture Reviewer • Business use case realization
• Business Designer • Business use-case model • Whole team • Scrum Master • Visualize the workflow
• Business-Model Reviewer • Business vision • Coding standard • Product Owner • Limit WIP
• Business-Process Analyst • Change request • TDD • Team • Measure and optimize lead time
• Capsule Designer • Configuration audit findings • Collective ownership • Sprint planning meeting
• Change Control Manager • Configuration management plan • Customer tests • Daily Scrum
• Code Reviewer • Data model • Pair programming • Sprint review
• Configuration Manager • Deployment model • Refactoring • Product backlogt
• Course Developer • Deployment plan • Planning game • Sprint backlog
• Database Designer • Design guidelines • Continuous integration • BUrndown chart
• Deployment Manager • Design model • Simple design
• Design Reviewer • Development case • Sustainable pace
• Designer • Development-organization • Metaphor
• Graphic Artist assessment • Small releases
• Implementer • End-user support mateirla
• Integrator • Glossary
• Process Engineer • Implementation model
• Project Manager • Installation artifacts
• Project Reviewer • Integration build plan
• Requirements Reviewer • Issues list
• Requirements Specifier • Iteration assessment
• Software Architect • Iteration plan
• Stakeholder • Manual styleguide
• System Administrator • Programming guidelines
• System Analyst • Quality assurance plan
• Technical Writer • Reference architecture
• Test Analyst • Release notes
•
•
•
Test Designer
Test Manager
Tester
•
•
Requirements attributes
Requirements
management plan
Do not develop an attachment
•
•
•
Tool Specialist
User-Interface Designer
Architectural analysis
•
•
•
Review record
Risk list
Risk management plan
to any one weapon
•

•
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)

Planning cadence (2w)

Release cadence (1w)

Kanban team 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

Retrospectives (4w)

Planning (on demand)

Release (on demand)

Henrik Kniberg 10
Both limit WIP, but in different ways
Scrum board Kanban board

To do Ongoing Done :o) To do Ongoing Done :o)

2
A A
B B
C C
D D

FLOW FLOW

WIP limited per unit of time WIP limited per workflow state
(iteration)

Henrik Kniberg 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 Few large teams Great! More options! Oh no, more complicated!

Low WIP limits High WIP limits

Few workflow states Many workflow states

Short iterations Long iterations

Little planning Lots of planning

.... etc ... .... etc ...

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 doesn’t allow change

PO
in mid-iteration
Wait until a To Do slot
becomes available!
Wait until next sprint! Or swap out C or D!

Scrum Kanban

To do Ongoing Done :o) To do Ongoing Done :o)

2 2
C A C A

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

Scrum Kanban – example 1 Kanban – example 2

Specialist Specialist
Cross-functional
Cross-functional team
Cross-functional team
team team

Henrik Kniberg 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 Long running task

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?)

Sprint 1 Sprint 2 Sprint 3

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

Scrum example 2 Scrum example 3 Kanban example 2

All products All products Color-coded swimlanes
Cross-product team Cross-product 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

Both are Lean 3.

and Agile
1. Individuals and Interactions
over Processes and Tools
2. Working Software
over Comprehensive Documentation
3. Customer Collaboration
over Contract Negotiation
4. Responding to Change
over Following a Plan
4.
Use Pull Systems to Avoid Overproduction
Level Out the Workload (Heijunka)
5. Build a Culture of Stopping to Fix Problems, to Get Quality Right the First Time
6. Standardized Tasks are the Foundation for Continuous Improvement and
Employee Empowerment
7. Use Visual Controls So No Problems are Hidden
8. Use Only Reliable, Thoroughly Tested Technology That Serves Your People and
Processes
9. Grow Leaders Who Thoroughly Understand the Work, Live the Philosophy, and
Teach It to Others
10. Develop Exceptional People and Teams Who Follow Your Company’s Philosophy
11. Respect Your Extended Network of Partners and Suppliers by Challenging Them
and Helping Them Improve
12. Go and See for Yourself to Thoroughly Understand the Situation (Genchi
Genbutsu)
13. Make Decisions Slowly by Concensus, Thoroughly Considering All Options;
Implement Decisions Rapidly
14. Become a Learning Organization Through Relentless Reflection (Hansei) and
Continuous Improvement (Kaizen)

Lean
Quality – Cost – Lead Time
People

Just in Stop the

Time Line
Kaizen

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 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
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
www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf
Differences
Scrum
Timeboxed iterations prescribed.
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
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
Kanban
Timeboxed iterations optional.
Commitment optional.
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