Kanban vs Scrum

Making the most of both

QCon, San Francisco Nov 18, 2009

Henrik Kniberg
Agile/Lean coach @ Crisp, Stockholm http://www.crisp.se/henrik.kniberg Background: developer, manager, entreprenuer

Board of directors

henrik.kniberg@crisp.se +46 70 4925284

Purpose of this presentation

To clarify Kanban and Scrum by comparing them ...so you can figure out how these may come to use in your context.

Henrik Kniberg

Split your organization

Scrum in a nutshell
Split your product
Large group spending a long time building a huge thing Small team spending a little time building a small thing ... but integrating regularly to see the whole

Optimize business value

$$$

Optimize process

Split time
January $ April

Henrik Kniberg

Typical Scrumboard

Henrik Kniberg

The bottom line

If you achieve these you can ignore the rest of the checklist. Your process is f ine. Delivering working, tested software every 4 weeks or less Delivering what the business needs most Process is continuously improving

Core Scrum
These are central to Scrum. Without these you probably shouldnt call it Scrum. Retrospective happens af ter every sprint Results in concrete improvement proposals Some proposals actually get implemented Whole team + PO participates PO has a product backlog (PBL) Top items are prioritized by business value Top items are estimated Estimates written by the team Top items in PBL small enough to fit in a sprint PO understands purpose of all backlog items Have sprint planning meetings PO participates PO brings up-to-date PBL Whole team participates Results in a sprint plan

Scrum Checklist
Henrik Kniberg Recommended but not always necessary
Most of these will usually be needed, but not always all of them. Experiment! Team has all skills needed to bring backlog items to Done Team members not locked into specific roles Iterations that are doomed to fail are terminated early PO has product vision that is in sync with PBL PBL and product vision is highly visible Everyone on the team participates in estimating PO available when team is estimating Estimate relative size (story points) rather than time Whole team knows top 1-3 impediments SM has strategy f or how to f ix top impediment SM focusing on removing impediments Escalated to management when team cant solve Team has a Scrum Master (SM) SM sits with the team PBL items are broken into tasks within a sprint Sprint tasks are estimated Estimates f or ongoing tasks are updated daily Velocity is measured All items in sprint plan have an estimate PO uses velocity f or release planning Velocity only includes items that are Done Team has a sprint burndown chart Highly visible Updated daily Daily Scrum is every day, same time & place PO participates at least a f ew times per week Max 15 minutes Each team member knows what the others are doing

the unofficial

Clearly def ined product owner (PO) PO is empowered to prioritize PO has knowledge to prioritize PO has direct contact with team PO has direct contact with stakeholders PO speaks with one voice (in case PO is a team) Team has a sprint backlog Highly visible Updated daily Owned exclusively by the team Daily Scrum happens Whole team participates Problems & impediments are surf aced Demo happens af ter every sprint Shows working, tested software Feedback received f rom stakeholders & PO Have Definition of Done (DoD) DoD achievable within each iteration Team respects DoD

Whole team believes plan is achievable PO satisfied with priorities Timeboxed iterations Iteration length 4 weeks or less Always end on time Team not disrupted or controlled by outsiders Team usually delivers what they committed to Team members sit together Max 9 people per team

Scaling
These are pretty f undamental to any Scrum scaling ef f ort. You have a Chief Product Owner (if many POs) Dependent teams do Scrum of Scrums Dependent teams integrate within each sprint

Positive indicators
Leading indicators of a good Scrum implementation. Having fun! High energy level. Overtime work is rare and happens voluntarily Discussing, criticizing, and experimenting with the process

Henrik Kniberg

PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definition of Done http://www.crisp.se/scrum/checklist | Version 2.1 (2009-08-17)

Typical waterfall => Scrum evolution

1. Waterfall
Requirements

2. Scrum But
Requirements

3. Scrum
PO

Feature team 1 Design Design & code

Feature team 2

Code

Test

Test

Henrik Kniberg

Kanban in a nutshell
Visualize the workflow Limit WIP (work in progress) Measure & optimize flow
To do 5
H

Dev 3
G

Test 2
D

Release 3
C

Done!
A B

K FLOW

Useful starting point for more info: http://www.limitedwipsociety.org

Roots of Kanban
Buyer

Kan Ban Visual Card

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

Kanban in software development

Henrik Kniberg

Typical Scrum => Kanban evolution

Scrum step 1
Feature team 1 Scrum Feature team 2 Scrum Feature team 2 Scrum Feature team 1 Scrum

Scrum step 2
Feature team 2 Scrum Feature team 2 Scrum

Scrum + Kanban
Feature team 1 Scrum Feature team 2 Scrum Feature team 2 Scrum

Operations / support team Scrum

Operations / support team Kanban

Henrik Kniberg

10

Thinking tools

Tool
anything used as a means of accomplishing a task or purpose. - dictionary.com

a.k.a. mindsets or philosophies Lean Agile Systems Thinking

Toolkits
Scrum RUP

Theory of Constraints

a.k.a. frameworks XP

Physical tools

Kanban

Process tools

a.k.a. organizational patterns

Product Owner role Pair programming

Visualize the workflow

To do
5

Dev
3

Test
2

Release
3

Done!
A B

H G K

FLOW

Henrik Kniberg

11

Can we compare Kanban and Scrum? Should we?

Henrik Kniberg

12

Any tool can be misused

The old tool was better!

Never blame the tool!

13

Henrik Kniberg

13

Compare for understanding, not judgement

More prescriptive
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

More adaptive
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)
Visualize the workflow Limit WIP Measure and optimize lead time

Do Whatever (0)

Do not develop an attachment to any one weapon or any one school of fighting
Miyamoto Musashi 17th century samurai

Henrik Kniberg

14

Distinguish the tool itself from specific usage techniques

Specific patterns, techniques, best practices, etc

Scrum core

Kanban core

Henrik Kniberg

15

Scrum prescribes 3 roles

Product owner
PO

Team

Scrum Master

SM

Henrik Kniberg

16

Scrum prescribes timeboxed iterations

Scrum team Kanban team 1 Kanban team 2
Retrospectives (4w) Planning cadence (2w) Release cadence (1w) week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8

Sprint 1
Review (release?)

Sprint 2
Retrospective

Plan & commit

week 1

week 2

week 3

week 4

week 5

week 6

week 7

week 8

Kanban team 3
Retrospectives (4w) Planning (on demand) Release (on demand)

week 1

week 2

week 3

week 4

week 5

week 6

week 7

week 8

Henrik Kniberg

17

Both limit WIP, but in different ways

Scrum board To do Ongoing Done :o)
A B C D
FLOW

Kanban board To do Ongoing Done :o)

B C D
FLOW

WIP limited per unit of time (iteration)

WIP limited per workflow state

Henrik Kniberg

18

Both are empirical

Capacity
(aka velocity)

Lead time
(aka cycle time)

Quality
(defect rate, etc)

Predictability
(SLA fulfillment, etc)

Kanban is more configurable

Many small teams Low WIP limits Few workflow states Short iterations Little planning .... etc ...

Few large teams High WIP limits Many workflow states Long iterations Lots of planning .... etc ...

Great! More options!

Oh no, more decisions!

Henrik Kniberg

19

Id like to have E!

Scrum discourages change in mid-iteration

Wait until next sprint!

PO
Wait until a To Do slot becomes available! Or swap out C or D!

Scrum To do
C D

Kanban Ongoing Done :o)

A B

To do 2
C D

Ongoing Done :o) 2

A B

FLOW

FLOW

Policies

Henrik Kniberg

20

Scrum board is reset between each iteration

Scrum
First day of sprint Mid-sprint Last day of sprint

Kanban
Any day

Henrik Kniberg

21

Scrum prescribes cross-functional teams

Scrum team Kanban team 1 Kanban team 2

Cross-functional team

Specialist Cross-functional team

Specialist team

Henrik Kniberg

22

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

23

Scrum prescribes estimation and velocity

V= 8

V= 7

V= 9

1 2

2 3 1

2 3 1
Sprint 2

1 2

2 2 1

Likely velocity: 8 per sprint (sustainable pace?)

Sprint 1

Sprint 3

Henrik Kniberg

24

Both allow working on multiple products simultaneously

Scrum example 1
Green Product Green team Yellow Product Yellow team

Kanban example 1
Color-coded tasks

Scrum example 2
All products Cross-product team

Scrum example 3
All products Cross-product team

Kanban example 2
Color-coded swimlanes

Henrik Kniberg

25

The Toyota Way

Both are Lean and Agile

Agile Manifesto
1. 2. Individuals and Interactions over Processes and Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan

1.

2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

3. 4.

Henrik Kniberg

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 Companys 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) 26

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

Policies Henrik Kniberg 27

Minor difference:

Scrum prescribes daily meetings

... but many Kanban teams do that anyway.

Henrik Kniberg

28

Minor difference:

In Scrum, burndown charts are prescribed

No specific types of diagrams prescribed in Kanban. Teams use whatever they need.

Cumulative Flow

Henrik Kniberg

29

Evolve your own unique board!

Henrik Kniberg

Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people

30

Henrik Kniberg

Kanban www.crisp.se/kanban/example kick-start example

Ongoing Done
2009-09-01 orem ipsum dolor sit orem ipsum dolor amet, co nse amet, co sit nse ctetur ctetur adi pis cing elit nisl

Next 2

Analysis 3

Ongoing
2009-08-30

Development 3
orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur

Done

Ongoing
2009-08-27 orem ipsum dolor sit amet, adi pis cing elit nisl

Acceptance Prod 2
Done
2009-08-20

version 1.2 2009-11-16

2009-09-08

orem ipsum dolor sit amet, co adi pis cing elit nisl

orem olor sit amet, co nse ctetur adi pis cing elit nisl

xxxx kjd orem ipsum djdolor d xxx sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur

orem ipsum dolor sit amet, co nse ctetur

orem ipsum dolor sit amet, co nse ctetur

2009-09-02

2009-08-29 orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl 2009-08-25 orem ipsum dolor sit ctetur adi pis cing elit nisl

orem ipsum dolor sit amet, co nse

orem ipsum dolor sit amet, co nse orem ipsum dolor sit amet, co nse ctetur ctetur

Definition of Done: Goal is clear First tasks defined Story split (if necessary)

Definition of Done: Code clean & checked in on trunk Integrated & regression tested Running on UAT environment

Definition of Done: Customer accepted Ready for production

Feature / story
Date when added to board

Hard deadline
(if applicable)

Task / defect
(description)

=task

(description)

=defect

1. Panicfeatures

What to pull first

(should be swarmed and kept moving. Interrupt other work and break WIP limits as necessary) (only if deadline is at risk)

2009-08-20

2009-09-30

= priority = panic

(description)

= completed = blocked = who is doing this right now

(description)

(description)

Why

Who is analyzing / testing right now

(description)

2. Priority features 3. Hard deadline features 4. Oldest features

Comparison: Typical Scrum board & Kanban board

Scrum
Product backlog Sprint backlog

E E F F G HG

Committed Ongoing Done :o)

A B

J H L K M

I D

Kanban
Backlog Next
2 Ongoing

Dev
3 Done

In production :o)
X Q

F I J L K M H

D G E

B C

Henrik Kniberg

32

Scenario 1 one piece flow

Backlog
A G C F H J M L K I E D

Next

Dev
3
Ongoing Done

In production :o)

Henrik Kniberg

33

Scenario 1 one piece flow

Backlog

Next

Dev
3
Ongoing Done

In production :o)

G C F H J M L K I E D

A B

Henrik Kniberg

34

Scenario 1 one piece flow

Backlog

Next

Dev
3
Ongoing A Done

In production :o)

G C F H J M L K I E D B

Henrik Kniberg

35

Scenario 1 one piece flow

Backlog

Next

Dev
3
Ongoing Done A B

In production :o)

G F H J M L K I E

C D

Henrik Kniberg

36

Scenario 1 one piece flow.

Backlog

Next

Dev
3
Ongoing C Done

In production :o)
A B

G D F H J M L K I E

Henrik Kniberg

37

Scenario 2 Deployment problem

Backlog
PO
A G C F H J M L K I E D B

Next

Dev
3
Ongoing Done

In production :o)

Henrik Kniberg

38

Scenario 2 Deployment problem

Backlog
PO
G C F H J M L K I E D

Next
A B

Dev
3
Ongoing Done

In production :o)

Henrik Kniberg

39

Scenario 2 Deployment problem

Backlog
PO
G F H J M L K I E

Next

Dev
3
Ongoing A B Done

In production :o)

C D

Henrik Kniberg

40

Scenario 2 Deployment problem

Backlog
PO
G

Next

Dev
3
Ongoing C Done A

In production :o)

D F H J M L K I E

Henrik Kniberg

41

Scenario 2 Deployment problem

Backlog
PO
G

Next

Dev
3
Ongoing C Done A B

In production :o)

D F H J M L K I E

!?

Henrik Kniberg

42

Scenario 2 Deployment problem

Backlog
PO
G

Nexet
2

Dev
3
Ongoing Done A B C

In production :o)

!?
D E I L K

F H J M

Henrik Kniberg

43

Scenario 2 Deployment problem

Backlog
PO
G

Next

Dev
3
Ongoing Done A

In production :o)

D F H J M L K I E

B C

Henrik Kniberg

44

Scenario 2 Deployment problem

Backlog
PO
G

Next

Dev
3
Ongoing Done

In production :o)
A

D F H J M L K I E C

Henrik Kniberg

45

Scenario 2 Deployment problem

Backlog
PO
G F H J M L K I

Next

Dev
3
Ongoing D E C Done

In production :o)
A B

Henrik Kniberg

46

One day in Kanban land

http://blog.crisp.se/henrikkniberg/tags/kanban/

Henrik Kniberg

47

Kanban & Scrum

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

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 Doesnt prescribe any roles A kanban board is persistent Prioritization is optional.48

Henrik Kniberg

Dont be dogmatic
Go away! Dont talk to us! Were in a Sprint. Come back in 3 weeks. Though Shalt Limit WIP

Henrik Kniberg

49

Essential skills needed for both Kanban and Scrum

Splitting the system into deliverable increments Software craftsmanship
Teams not businessoriented

Retrospectives

Root-cause analysis
Teams not focused Teams dont have own PO PO doesnt have own team

Team not getting feedback from customer

Ineffective requirements com munication

Unclear roles & responsibilities

Teams grouped by com ponent

Lack of team spirit

Too much focus on written specs

Lack of discipline in teams

Feature split across m ultiple team s

Hard to plan

Delayed releases

Lack of transparancy

No burndowns

Fear of committing Problems estimating Not m easuring velocity Teams disrupted during sprint Cutting quality instead of scope

Bad throughput in developm ent

Difficult to release Hard to change the code

Many defects

Lack of test automation

Many operational problem s

Customers dissatisfied

http://www.crisp.se/henrik.kniberg/cause-effect-diagrams.pdf

Henrik Kniberg

50

Take-away points
1. Know your goal Hint: Agile/Lean/Kanban/Scrum isnt it. 2. Never blame the tool Tools dont fail or succeed. People do. There is no such thing as a good or bad tool. Only good or bad decisions about when, where, how, and why to use which tool. 3. Dont limit yourself to one tool Learn as many as possible. Compare for understanding, not judgement. 4. Experiment & enjoy the ride Dont worry about getting it right from start. The only real failure is the failure to learn from failure.
Henrik Kniberg 51

Henrik Kniberg

52