Anda di halaman 1dari 52

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 unofficial

The bottom line

Core Scrum

If you achieve these you can ignore the


rest of the checklist. Your process is f ine.

These are central to Scrum. Without these


you probably shouldnt call it Scrum.

Delivering working, tested


software every 4 weeks or less
Delivering what the
business needs most
Process is
continuously improving

Clearly def ined product owner


(PO)

Scrum Checklist

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)

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

Sprint tasks are estimated


Estimates f or ongoing tasks
are updated daily

PO is empowered to
prioritize

Top items are prioritized


by business value

Iterations that are doomed to


fail are terminated early

PO has knowledge to
prioritize

Top items are estimated

PO has direct contact with


team

Estimates written by the


team

PO has product vision that is in


sync with PBL

PO has direct contact with


stakeholders

Top items in PBL small


enough to fit in a sprint

PO speaks with one voice


(in case PO is a team)

PO understands purpose
of all backlog items

Team has a sprint backlog

Have sprint planning meetings

Highly visible

PO participates

Updated daily

PO brings up-to-date PBL

Owned exclusively by the


team

Whole team participates

Whole team participates

All items in sprint plan have


an estimate

Everyone on the team


participates in estimating

PO uses velocity f or
release planning

PO available when team is


estimating

Velocity only includes


items that are Done

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

Problems & impediments


are surf aced

Escalated to management
when team cant solve

Whole team believes plan


is achievable
PO satisfied with
priorities

Team has a Scrum Master (SM)


SM sits with the team

Timeboxed iterations
Demo happens af ter every
sprint
Shows working, tested
software
Feedback received f rom
stakeholders & PO
Have Definition of Done (DoD)

Henrik Kniberg

DoD achievable within


each iteration
Team respects DoD

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

Velocity is measured

PBL and product vision is highly


visible

Results in a sprint plan


Daily Scrum happens

PBL items are broken into


tasks within a sprint

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

Scaling

Positive indicators

These are pretty f undamental to any


Scrum scaling ef f ort.

Leading indicators of a
good Scrum implementation.

You have a Chief Product


Owner (if many POs)

Having fun! High energy level.

Dependent teams do Scrum of


Scrums

Overtime work is rare and


happens voluntarily

Dependent teams integrate


within each sprint

Discussing, criticizing, and


experimenting with the process

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

3. Scrum
PO

Requirements
Feature
team 1

Design

Feature
team 2

Design & code

Code

Test

Henrik Kniberg

Test

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

To do
5

Dev
3

Test
2
D

Release
3
C

Done!
A
B

K
FLOW

Useful starting point for more info:


http://www.limitedwipsociety.org

Roots of Kanban

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.

Henrik Kniberg

Taiichi Ohno
Father of the
Toyota Production System

Kanban in software development

Henrik Kniberg

Typical Scrum => Kanban evolution


Scrum step 1
Feature
team 1

Feature
team 2

Feature
team 2

Scrum

Scrum

Scrum

Scrum step 2
Feature
team 1
Scrum

Feature
team 2
Scrum

Feature
team 2
Scrum

Operations / support team


Scrum

Henrik Kniberg

Scrum + Kanban
Feature
team 1
Scrum

Feature
team 2
Scrum

Feature
team 2
Scrum

Operations / support team


Kanban

10

Thinking tools

a.k.a. mindsets or philosophies

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

Lean

Physical tools

Agile

Systems Thinking

Theory of Constraints

Toolkits

a.k.a. frameworks
RUP

Scrum

XP

Kanban

Process tools

a.k.a. organizational patterns

Product Owner role


Pair programming

Visualize the workflow


To do
5

Dev
3

Test

Release

Done!
A

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

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

Scrum
(9)

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

14

Distinguish the tool itself


from specific usage techniques
Specific patterns, techniques,
best practices, etc

Scrum
core

Henrik Kniberg

Kanban
core

15

Scrum prescribes 3 roles

Product
owner

Team

Scrum
Master

PO
SM

Henrik Kniberg

16

Scrum prescribes timeboxed 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

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

17

Both limit WIP, but in different ways


Kanban board

Scrum board
To do

Ongoing Done :o)

To do

Ongoing Done :o)

A
B

B
C

D
FLOW

WIP limited per unit of time


(iteration)

Henrik Kniberg

FLOW

WIP limited per workflow state

18

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

High WIP limits

Short iterations

.... etc ...

Great! More options!

.... etc ...

19

Id like to have E!

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

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

Cross-functional
team

Henrik Kniberg

Kanban team 2

Specialist Cross-functional
team

Specialist
team

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

Henrik Kniberg

Long running task

23

Scrum prescribes estimation and velocity

V= 8

V= 7

2
2

Sprint 1

Henrik Kniberg

2
3

1
Sprint 2

V= 9

1
3

1
2

2
2

Likely velocity: 8 per sprint


(sustainable pace?)

Sprint 3

24

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

Cross-product team

Kanban example 2
Color-coded swimlanes

25

The Toyota Way

Both are Lean


and Agile
Agile Manifesto
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

1.

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

Henrik Kniberg

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

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

Henrik Kniberg

Next
2

Analysis
3

Development
3

Ongoing

Ongoing Done
2009-09-01

orem ipsum dolor sit


amet, co adi pis cing
elit nisl

2009-08-20
orem olor sit amet, co
nse ctetur adi pis cing
elit nisl

orem ipsum dolor


sit amet, co nse
ctetur

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

orem ipsum dolor


sit amet, co nse

2009-08-25
orem ipsum dolor sit
ctetur adi pis cing elit
nisl

orem ipsum dolor


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

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

Feature / story
Date when
added to board

2009-09-30

(description)

Done

orem ipsum dolor


sit amet, co nse
ctetur

orem ipsum dolor


sit amet, co nse
ctetur

2009-09-02

2009-08-20

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

orem ipsum dolor


sit amet, co nse
ctetur

xxxx kjd
orem ipsumdjdolor
d xxx
sit amet, co nse
ctetur

orem ipsum dolor


sit amet, co nse
ctetur

Acceptance Prod
2
2009-08-27

2009-09-08

2009-08-30

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

Done

version 1.2
2009-11-16

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

Hard deadline
(if applicable)

= priority
= panic

Who is analyzing /
testing right now

Task / defect
(description)

=task

(description)

Why

(description)

(description)

(description)

=defect

= completed
= blocked
= who is doing
this right now

Definition of Done:
Customer accepted
Ready for production

What to pull first

1. Panicfeatures

(should be swarmed and kept


moving. Interrupt other work
and break WIP limits as
necessary)

2. Priority features
3. Hard deadline features
(only if deadline is at risk)

4. Oldest features

Comparison:
Typical Scrum board & Kanban board
Scrum
Sprint backlog

Product
backlog

E
E
F
F
G
HG

Committed Ongoing Done :o)


A

B
I

J H
L
K
M

Kanban

F
H

Dev

Next

Backlog

I
J L
K
M

Henrik Kniberg

Ongoing

Done

In production :o)
X
Q

32

Scenario 1 one piece flow

Next

Backlog
A

Dev

In production :o)

Ongoing

Done

G
C
F
H
J
M

D
I

L
K

Henrik Kniberg

33

Scenario 1 one piece flow

Next

Backlog

Ongoing

Done

C
F
H
M

In production :o)

Dev

D
I

L
K

Henrik Kniberg

34

Scenario 1 one piece flow

Backlog

Ongoing

Done

C
F
H
M

In production :o)

Dev

Next

D
I

L
K

Henrik Kniberg

35

Scenario 1 one piece flow

Dev

Next

Backlog

Ongoing

In production :o)

Done
A

F
H
J
M

I
L
K

Henrik Kniberg

36

Scenario 1 one piece flow.

Dev

Next

Backlog

In production :o)

Ongoing

Done

G
D

A
B

F
H
J
M

I
L
K

Henrik Kniberg

37

Scenario 2 Deployment problem

Next

Backlog
PO
A

Dev

In production :o)

Ongoing

Done

G
C
F
H
J
M

D
I

L
K

Henrik Kniberg

38

Scenario 2 Deployment problem

Next

Backlog

PO

Ongoing

Done

C
F
H
M

In production :o)

Dev

D
I

L
K

Henrik Kniberg

39

Scenario 2 Deployment problem

Dev

Next

Backlog
PO
G

In production :o)

Ongoing

Done

F
H
J
M

I
L
K

Henrik Kniberg

40

Scenario 2 Deployment problem

Dev

Next

Backlog
PO

Ongoing
C

G
D

In production :o)

Done
A

F
H
J
M

I
L
K

Henrik Kniberg

41

Scenario 2 Deployment problem

Backlog
PO

G
D
F
H
J
M

Dev

Next

In production :o)

Ongoing

Done

!?

I
L
K

Henrik Kniberg

42

Scenario 2 Deployment problem

Backlog
PO

F
H
M

In production :o)

Ongoing

!?

Dev

Nexet

Done
A

I
L
K

Henrik Kniberg

43

Scenario 2 Deployment problem

Next

Backlog
PO

F
H
M

In production :o)

Ongoing

Done
A

Dev

I
L
K

Henrik Kniberg

44

Scenario 2 Deployment problem

Next

Backlog
PO

Dev

In production :o)

Ongoing

Done
A

G
D
F
H
J
M

B
C

I
L
K

Henrik Kniberg

45

Scenario 2 Deployment problem

Backlog
PO

In production :o)

Ongoing

Done

A
B

Dev

Next

C
I

L
K

Henrik Kniberg

46

One day in Kanban land


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

Henrik Kniberg

47

Kanban & Scrum

www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf

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)

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

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

Henrik Kniberg

Though Shalt
Limit WIP

49

Retrospectives

Essential skills needed


for both Kanban and Scrum
Splitting the system into
deliverable increments
Software
craftsmanship

Root-cause analysis
Teams not
focused
Teams not
businessoriented

Teams dont have


own PO

Team not getting


feedback from
customer

Teams grouped
by com ponent

Ineffective
requirements
com munication

Hard to
plan

Delayed releases

Not
m easuring
velocity
Teams disrupted
during sprint

Many operational
problem s

Lack of discipline
in teams

Lack of
transparancy

No
burndowns

Bad throughput in
developm ent

Fear of
committing
Problems
estimating

Unclear roles &


responsibilities

Too much focus


on written specs

Lack of team
spirit

Feature split across


m ultiple team s

PO doesnt have
own team

Cutting quality
instead of scope

Many
defects

Difficult to
release

Lack of test
automation

Hard to
change the
code

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

Anda mungkin juga menyukai