Kanban Tutorial - Jfokus

Kanban

A Lean approach to Agile software development JFokus January 26, 2010

Henrik Kniberg Agile/Lean coach www.crisp.se Board of directors

[email protected] 070 4925284

Goals of this tutorial Basic understanding of Kanban Where it came from What problem it tries to solve Underlying Lean principles How it looks like in practice How to get started

Henrik Kniberg

2

Exercise

Flow

3

Watch the baton, not the runner!

Henrik Kniberg

4

Cycle time Cycle time / lead time = The reliable, repeatable time from customer need until that need is satisfied (≈ time to market) Examples: • Time to get my hamburger • Time to resolve support request • Time to get home from work • Time to deliver a feature

Your system & resources

Item in

Item out

Not to be confused with Iteration/Sprint length = release frequency / cadence length

Henrik Kniberg

5

Minimize cycle time

Watch the baton!

Competitive advantage Detect defects earlier Less time for change to happen

Henrik Kniberg

6

Problem: Invisible baton Team 1

Team 2

Managers who don’t know how to measure what they want settle for wanting what they can measure Russel Ackoff

Henrik Kniberg

7

Optimizing resource utilization = suboptimizing cycle time

Baton in

Baton out 100% runner utilization => Lose the race

Car in

Car out 100% Road utilization => Long time to get home

CPU: 100%

Http://....

Request in

Henrik Kniberg

CPU: 100% CPU: 100%

100% Server utilization => Long response time

....

Response out

8

Queuing theory: Little’s law Smaller batch size => faster cycle time

Little’s law

Total Cycle Time =

2 liters per second

slow

Henrik Kniberg

Number of Things in Process Average completion rate

2 liters per second

Fast

9

Minimize batch size Knowledge is perishable 1 fresh banana per day Monday

Tuesday

Wednesday

Thursday

Friday

Wednesday

Thursday

Friday

... or 5 rotten bananas per week? Monday

Henrik Kniberg

Tuesday

10

Little’s law in action Focusing

Total Cycle Time =

Number of Things in Process Average completion rate

Short cycle time

1 task in progress

Task A

Task B

Task C

Timeline

Multitasking

3 tasks in progress

Long cycle time

A1 B1

B3

B2 C1

Henrik Kniberg

A3

A2 C2

C3 11

Q: What causes multitasking? A: Optimizing for max resource utilization

P

T

Project A Project B Project C Project D

Q1

Henrik Kniberg

Q2

Q3

Q4

12

Value stream mapping Design-ready games

Game backlog

15

8 Sam 2d

1m

Concept pres.

2h

6m

Lisa assigns resources

4h

3 m value added time 25 m cycle time

Production-ready games

1d

1w

Graphics design

Sound design

1m

3w

12

Dev 6m

6m

Integr. & deploy

3m (1m+2m)

3w

Process = 12% cycle efficiency

Cross-functional game team 3-4 m cycle time = 6-8x faster

Game team (graphics, sound, dev, integrate) 3-4 months

Henrik Kniberg

13

Optimize the whole I’m fast!

We’re slow!

6 months

Joe

Dave

Lisa

Done!

3 months

We’re alot faster!

Joe

I’m a bit slower

Dave Lisa January

February

Henrik Kniberg

Done!

March

April

May

June

July

14

Problem: Invisible baton Team 1

Team 2

Managers who don’t know how to measure what they want settle for wanting what they can measure Russel Ackoff

Henrik Kniberg

15

It’s hard to optimize something that you can’t see

16

First step: Visualize the baton! Team 1

Todo orem ipsum dolor 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 orem ipsum dolor sit amet, co nse ctetur

Team 2

Done

Doing orem ipsum dolor 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 orem ipsum dolor sit amet, co nse ctetur

Avg lead time:

Henrik Kniberg

Todo

this week

Doing

Done

this week

orem ipsum dolor 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




20 days


Avg lead time:


3 days 17

Kaizen

18

Both are empirical

Capacity

Lead time

Quality

Predictability

(aka velocity)

(aka cycle time)

(defect rate, etc)

(SLA fulfillment, etc)

Kanban is HIGHLY 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

Almost always a good idea Visualize the workflow Limit WIP (work in process) Short feedback loops Focus on quality Cadences

Henrik Kniberg

20

Exercise

Pull

21

Limit work to capacity Input: 3 customers / hour

Henrik Kniberg

Output capacity: 2 customers / hour

22

Pull vs Push

Assigning tasks = push Taking tasks = pull

Push

Pull

Henrik Kniberg

23

Example: Supermarket pull

Henrik Kniberg

24

Example: Feature pull

Henrik Kniberg

25

Why feature pull is important Features and functions used in a typical system: Half of the features we build are never used!

Always 7%

Never 45%

Often 13% Sometimes 16%

Rarely 19% Source: Standish Group Study Reported at XP2002 by Jim Johnson, Chairman

Henrik Kniberg

26

Kanban

27

Kanban

看板 ”Visual Card”

Signaling system Visual Limited in supply

Henrik Kniberg

28

Kanban @ Imperial Palace Gardens

Henrik Kniberg

29

Kanban in your wallet

Darn. Forgot to limit.

Henrik Kniberg

30

Kanban @ Toyota Buyer

Consume

Detach

Supplier

Receive

Ship

Allocate

Manufacture

The tool used to operate the [Toyota Production] system is kanban.

Henrik Kniberg

Taiichi Ohno Father of the Toyota Production System

31

Kanban in SW development Pioneered by David Anderson in 2004

Visualize the workflow Limit WIP (work in progress) Measure & optimize flow Backlog 5

Dev 3

UAT Deploy Done 3 2 orem ipsum dolor sit amet, co nse ctetur







FLOW

Henrik Kniberg

Avg lead time:

12 days

32

Evolve your own board!

Henrik Kniberg

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

33

One day in Kanban land

34

”One day in Kanban land” http://blog.crisp.se/henrikkniberg/tags/kanban/

Henrik Kniberg

35

Scenario 1 – one piece flow

Next

Backlog A

2

Dev

In production :o)

3

Ongoing

Done

B

G C F H J M

D I

L K

Henrik Kniberg

E

36


Next

Backlog

2

Ongoing

Done

B

C F H M

In production :o)

3

A

G

J

Dev

D I

L K

Henrik Kniberg

E

37


Backlog

2

Ongoing

Done

B

C F H M

In production :o)

3

A

G

J

Dev

Next

D I

L K

Henrik Kniberg

E

38


Dev

Next

Backlog

2

Ongoing

C

G

D

In production :o)

3

Done A

B

F H J M

I L K

Henrik Kniberg

E

39

Scenario 1 – one piece flow.

Dev

Next

Backlog

2

In production :o)

3

Ongoing

Done

C

G D

A B

F H J M

I L K

Henrik Kniberg

E

40

Scenario 2 – Deployment problem

Next

Backlog PO A

2

Dev

In production :o)

3

Ongoing

Done

B

G C F H J M

D I

L K

Henrik Kniberg

E

41


Next

Backlog

2

PO

Ongoing

Done

B

C F H M

In production :o)

3

A

G

J

Dev

D I

L K

Henrik Kniberg

E

42


Dev

Next

Backlog PO G

2

In production :o)

3

Ongoing

C

A

D

B

Done

F H J M

I L K

Henrik Kniberg

E

43


Dev

Next

Backlog PO

2

Ongoing C

G D

In production :o)

3

Done A

B

F H J M

I L K

Henrik Kniberg

E

44


Backlog PO

2

G D F H J M

Dev

Next

In production :o)

3

Ongoing

Done

C

A

!?

B

I L K

Henrik Kniberg

E

45


Backlog PO

2

F H M

In production :o)

3

Ongoing

!?

G

J

Dev

Nexet

Done A

D

B

E

C

I L K

Henrik Kniberg

46


Next

Backlog PO

2

F H M

In production :o)

3

Ongoing

Done A

G

J

Dev

D

B

E

C

I L K

Henrik Kniberg

47


Next

Backlog PO

2

Dev

In production :o)

3

Ongoing

Done A

G D F H J M

E

B C

I L K

Henrik Kniberg

48


Backlog PO

In production :o)

3

Ongoing

Done

H

A B

E

F

M

2

D

G

J

Dev

Next

C I

L K

Henrik Kniberg

49

Bottlenecks

50

Theory of constraints – Smooth Flow Goal

Reality

Strategy

51

Theory of constraints All systems have a bottleneck When you fix it, it jumps to somewhere elese. The whole system performs only as well as its bottleneck Ensure you have slack before & after the bottleneck Happens automatically with pull scheduling Use the slack to fix the bottleneck

Henrik Kniberg

52

How to find your bottleneck Without WIP limits

• Busy at bottleneck • Slack downstream • Queue upstream

Next

Dev

Test

Integrate Deploy




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

Expensive queue


Cheap queue

With WIP limits Next orem ipsum dolor sit amet, co nse orem ipsum dolor orem ipsum dolor ctetur sit amet, co nse sit amet, co nse orem ipsum dolor ctetur orem ipsum dolor ctetur sit amet, co nse sit amet, co nse ctetur ctetur orem ipsum dolor orem ipsum dolor sit amet, co nse orem ipsum dolor sit amet, co nse ctetur sit amet, co nse ctetur orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur

Henrik Kniberg

3

Dev

2

Test

2

Integrate Deploy

3

3



53

Knows a bit about many things

Goal: ”T-shaped” people

Knows a lot about one thing

Team Skills matrix

I can test, but I’m not so good at it.

Test

DB

Web

Java

Domain

CM

I don’t know CM at all. But I’m willing to learn!

I’m good at Java!

Lisa Joe Fred Jenny David Erik

Henrik Kniberg

54

Kanban allows both specialists & generalists Backlog

3


Design

2

Fold

2



Tape

1

Trim

4

3



Henrik Kniberg

Draw


55

Cumulative Flow Diagram (CFD)

Backlog orem ipsum dolor sit amet, co nse ctetur


Day 4 Dev

Test

Prod


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

Henrik Kniberg

56

Cadence

57

Daily standup meeting

Henrik Kniberg

Source: Visual management blog

http://www.xqa.com.ar/visualmanagement/ 2009/04/daily-scrum-against-the-board/

58

Cadence 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

59

Reduce transaction costs Next

3

Dev

Test

2

2

Integrate Deploy

3

Trans cost

Trans cost

Cost of initializing test environment

Economies of Scale ”We need to do big batches because transaction cost is high”

Henrik Kniberg

3

Cost of restarting server

Economies of Flow (Lean) ”We need to minimize transaction cost so we can do smaller batches”

Automate init of test environment Implement hot-reload on server

60

Quality

61

Quality

Defects per unit of valued work

Value demand

Failure demand

Henrik Kniberg

62

Lean principle: Stop the Line The build server is your friend! Really!

Henrik Kniberg

63

Optimizing the WIP limit

64

Optimizing the WIP limit Too low WIP limit To do

Doing

1


Done orem ipsum dolor sit amet, co nse ctetur

Just Right WIP limit To do orem ipsum dolor sit amet, co nse ctetur


Slow flow (end-to-end) People often idle

Doing

2

Done orem ipsum dolor sit amet, co nse ctetur


Zzzzzzzzz

To do

Doing

5

Done


Tasks rarely idle People sometimes idle (slack)

Henrik Kniberg

Too high WIP limit


Fast flow

People never idle

Lack of wall space...

Slow flow


Tasks often idle

65

Use WIP limits to break vicious cycles Releasing is a Pain

Release seldom

Releasing is easy

Big releases

Long cycle time

High WIP Henrik Kniberg

Release often

Small releases

Low quality

Short cycle time

Low WIP

WIP limits

High quality

WIP limits 66

Evolution of a Kanban board

67

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


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



2009-09-02

2009-08-20

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


xxxx kjd orem ipsumdjdolor d xxx 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

Definition of Done: • Customer accepted • Ready for production

Task / defect (description)

=task

(description)

Why

(description)

(description)

(description)

=defect

What to pull first •

Panicfeatures

• •

Priority features Hard deadline features

= completed = blocked = who is doing this right now

•

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

Oldest features

Estimation & planning

69

Estimating is optional in Kanban Scrum Velocity = 11

4 2 Sprint 1

1

4

Sprint 2

Sprint 3

Sprint 4

Kanban Long running task WIP limit = 3

Henrik Kniberg

Long running task

70

Lightweight estimation techniques T-shirt sizing S

S

Hours?

M

M Days?

Henrik Kniberg

SLA – service level agreement

L L

Example: SLA is 12 days • Can we do this item within 12 days? • If yes: just pull it in. • If no: reject it, or break it down, or estimate/negotiate

Weeks?

71

Example: estimation paradox Estimation is sometimes used to manage a problem that was caused by the estimation itself

Prestudies, estimation, resource allocation, approval

Develop, test, deploy

Process 8 days work cycle 5 months cycle time= 9 % efficiency

5 month cycle time

Scared of commitment

Lots of estimation & prestudy Henrik Kniberg

2 week cycle time Little or no estimation & prestudy

Little fear of commitment

WIP limits 72

Using Kanban to visualize the problem

Henrik Kniberg

73

Metrics

74

Cumulative Flow Diagram If we lower WIP limit from 6 to 2 in test we can probably halve the cycle time!

Metrics WIP (work in progress) Analyze 3

Dev

4

Test

6

Deploy

Release capacity (velocity)

Last week we released 8 things

3

Average capacity during Q1 was 6 story points per week

Quality Undecided 25% Value demand 15%

Failure demand 60%

Henrik Kniberg

Item #25 took 7 days

Cycle time

Medium-sized MMFs take < 8 days 95% of the time.

75

Misc patterns & Tips & Tricks

76

Process = collection of policies Visible on the board Brief Continuously renegotiated as needed Created on-demand Examples: Definition of Done What to do when WIP limit is exceeded Who decides priorities When do we do planning? Which types of work items to we pull first Service level agreements Henrik Kniberg

77

2 tier board with feature swimlanes

Henrik Kniberg

Source: David Anderson

78

2 tier board-within-board

Henrik Kniberg

Source: David Anderson

79

Stopping dead projects

FLOW

Henrik Kniberg

Source: Mattias Skarin

80

Manager removing impediments 2 slots on manager’s door If both are full, team can add a new one if they remove a less important one Team decides when issue is solved

Henrik Kniberg

Source: Mattias Skarin

81

Bootstrapping Kanban

82

Typical Scrum => Kanban evolution Step 1

Step 2

Feature team 1

Feature team 2

Feature team 2

Scrum

Scrum

Scrum

Feature team 1 Scrum


Step 3 Feature team 2 Scrum

Operations / support team Scrum

Henrik Kniberg




Operations / support team Kanban

83

Example: Kanbanizing a Scrum team

Before sprint

Henrik Kniberg

Sprint

After sprint

84

Kanban bootstrapping

1. Define your value stream • Which part do you intend to control? • Where is your input & output? 2. Define work item types Task Bug 3. Meet with upstream & downstream stakeholders • Policies, WIP limits • Input coordination • Output coordination • Target cycle time (SLA – service level agreement)

4. Create Kanban board (+ optionally electronic system)

5. Agree on time for daily standup 6. Agree on when to do retrospectives / operations reviews 7. Go! Iteratively improve. Henrik Kniberg

85

Wrapup

86

Recommendations Visualize existing process first, then optimize. Put the board in the team room Focus on exposing problems Keep the board clean & simple (just like your code...) Don’t try to get it perfect from start. Let it evolve. Don’t overuse metrics Involve the team & managers & stakeholders Take photos Make policies & agreements explicit. Negotiate. Consider getting a coach for Kanban bootstrapping

Henrik Kniberg

87

The Lean & Agile toolkit Values & Principles

Lean, Agile, Theory of Constraints, Systems Thinking, etc

Kanban

XP

Other lean tools (Value Stream Mapping, Root Cause Analysis, etc)

Scrum

Henrik Kniberg

88

Perfection is a direction, not a place

Henrik Kniberg

89

Expand your toolkit! www.crisp.se/utbildning Kanban starting points on the web: http://www.crisp.se/kanban http://www.limitedwipsociety.com

Certified ScrumMaster & Kanban Feb 17-19

Kanban Applied Feb 23

Henrik Kniberg & Mattias Skarin

Leading Lean Software Development March 4-5

Tom & Mary Poppendieck & Henrik Kniberg

Kanban coaching workshop April 29-31

David Anderson

Henrik Kniberg

90

Kanban Tutorial - Jfokus

Recommend Documents