Kanban vs Scrum - Crisp

Kanban vs Scrum. Henrik Kniberg - Crisp AB. Agile coach & Java guy. Cofounder / CTO of Goyada (mobile services). Deep Lean, Stockholm...

25 downloads 533 Views 3MB Size
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