Predictability & Measurement with Kanban

8/3/2019 Predictability & Measurement with Kanban

http://slidepdf.com/reader/full/predictability-measurement-with-kanban 1/32

Agile Cambridge

September 2011

Predictability & Measurementwith Kanban

David J. AndersonDavid J. Anderson & Associates

[email protected]



AaK

Book PublishedApril 2010

A 72,000 wordintro to the topic

Available from

djandersonassociates.com



http://www.limitedwipsociety.org

Yahoo! Groups: kanbandev

Yahoo! Groups: kanbanops

http://leankanbanuniversity.com

LinkedIn Groups: Software Kanban



AaK

Delivering predictability withKanban

requires some different techniquesfor different types of work such as

software maintenance and support

or

major project work



AaK

Service-oriented work



AaK

Create a regular delivery cadence

Develop a strong config management capability

Develop capability to deploy effectively

Build code with high quality



AaK

Lead Time Distribution

0

0.5

1

1.5

2

2.5

1 6 1 1

1 6

2 1

2 6

3 1

3 6

4 1

4 6

5 1

5 6

6 1

6 6

7 1

7 6

8 1

8 6

9 1

9 6

1 0 1

1 0 6

Days

# C R s

MARCH


0

0.5

1

1.5

2

2.5

3

3.5

1 8 1 5 2 2 2 9 3 6 4 3 5 0 5 7 6 4 7 1 7 8 8 5 9 2 9 9 1 0 6

1 1 3

1 2 0

1 2 7

1 3 4

1 4 1

1 4 8

Days

C R s &

B u g

APRIL

OutliersMajority of CRs range 30 -> 55

Understand capability by studying the naturalphilosophy of the work



AaK

For standard class items, offer a target lead time

based on the 2nd

confidence interval



AaKFor example, SLA of

51 days with 98% on-time(+2 sigma from mean)


0

0.5

1

1.5

2

2.5

3

3.5

1 8 1 5 2 2 2 9 3 6 4 3 5 0 5 7 6 4 7 1 7 8 8 5 9 2 9 9 1 0 6

1 1 3

1 2 0

1 2 7

1 3 4

1 4 1

1 4 8

Days

C R s &

B u g



AaK

51 days will not be good enough for some

feature requests, so offer a package of classes ofservice



AaK

Package of Classes with SLAs

As soon as possible Full transparency

100% on-time

providing 24 days advance notice

Up to 51 days

98% on-time guarantee

Up to 51 days

50% on-time



AaK

Lead time

Features Delivered

Standard Class Items

Fixed Date Items

Expedite Item

All t it l f i i



AaK

Allocate capacity across classes of service inorder to deliver against anticipated demand

5 4 43 2 2= 20 total

Allocation

10 = 50%

...

+1 = +5%

4 = 20%

6 = 30%

InputQueue

DevReady In Prog DoneDoneIn Prog

DevelopmentAnalysis BuildReady Test

ReleaseReady



AaK

John Seddon has observed thatallocating capacity in this fashion

“damages capacity”!

While this is theoretically possible it will almostnever happen because

(a) a simple policy can be implemented totemporarily re-allocate

(b) demand is rarely zero for a given type, thoughFixed Date class of service can be seasonal

(c) the tickets represent work, not workers, theworkforce is flexible. Classes of service &

capacity allocation insure people can keep busyimproving utilization not damaging it



AaK

Major Project Work



AaK

Requires all the same underlyingdata as used in service oriented

workplus



AaK

Major Project with two-tiered kanban board



AaK

Cumulative Flow andPredictive Modeling with S-Curve

Device Management Ike II Cumulative Flow

0

20

40

60

80

100

120140

160

180

200

220

240

1 0 - F e b

1 7 - F e b

2 4 - F e b

2 - M

a r

9 - M

a r

1 6 - M a r

2 3 - M a r

3 0 - M a r

Time

F e a t u r e

s

Inventory Started Designed Coded Complete

Typical S-curve



AaK

Simulating S-Curve with a Z


0

20

40

60

80

100

120140

160

180

200

220

240

1 0 - F e b

1 7 - F e b

2 4 - F e b

2 - M

a r

9 - M

a r

1 6 - M a r

2 3 - M a r

3 0 - M a r

Time

F e a t u r e

s


20%

60%

20%

Slope in middle3.5x - 5x slope

at ends 5x



AaK

Track actual throughput against projection


0

20

40

60

80

100

120140

160

180

200

220

240

1 0 - F e b

1 7 - F e b

2 4 - F e b

2 - M

a r

9 - M

a r

1 6 - M a r

2 3 - M a r

3 0 - M a r

Time

F e a t u r e

s


Track delta betweenplanned and actual

each day



AaK

Unplanned Work Report

Dark Matter

Scope Creep

M k l l b ild



AaK

Make a long term plan to buildplatform replacement


0

20

40

60

80

100

120140

160

180

200

220

240

1 0 - F e b

1 7 - F e b

2 4 - F e b

2 - M

a r

9 - M

a r

1 6 - M a r

2 3 - M a r

3 0 - M a r

Time

F e a t u r e

s


Slope in middle3.5x - 5x slope

at ends 5x

Required throughput (velocity)

2006 2008



AaK

We need average throughput (velocity) to peak

at 13 features per month over 24 months.



AaK

Little’s Law

ThroughputLead Time

WIP

=

Target to achieve plan

From observed capability

Treat as Fixed variable

Determines staffing level

Ch i h WIP li i i h



AaK

Changing the WIP limit withoutmaintaining the staffing level ratiorepresents a change to the way of

working. It is a change to thesystem design. And will produce achange in the observed ‘common

cause’ capability of the system

Pl b d l b d



AaK

Plan based on currently observedcapability and current working

practices. Do not assume processimprovements.

If changing WIP to reduce

undesirable effects (e.g.multitasking), get new sample data

(perform a spike) to observe the

new capability

Littl ’ L



AaK

Little’s Law

13 / month0.25 months

WIP

=

Target to achieve plan

From observed capability

Determines staffing level

WIP = 3.25, round up to 4.

Might be safe toround down to 3.

If current working practice is 1 unit WIP perperson then 3 people are needed

Slightly over-allocate the intangible class of



AaK

Slightly over-allocate the intangible class ofservice (green) to compensate against expediting

5 4 43 2 2= 20 total

Allocation

12 = 60%

...

+1 = +5%

4 = 20%

4 = 20%

InputQueue

DevReady In Prog DoneDoneIn Prog

DevelopmentAnalysis BuildReady Test

ReleaseReady

C l i



AaK

Conclusions

F S i i t d k t



AaK

For Service-oriented work, createpredictability with

a regular delivery cadencea strong config management capabilitycapability to deploy effectivelycode with high quality

For major projects understand peak throughput (velocity)

model the s-curve on work complete

treat the avg. lead time as the fixed variableuse Little’s Law to calculate WIP limits and staffing levels

Th k !



AaK

Thank you!

[email protected]://www.agilemanagement.net/

Ab t

http://www.agilemanagement.net/

http://www.agilemanagement.net/



AaK

About… David Anderson is a thought leader inmanaging effective software teams. He leadsa consulting firm dedicated to improving

economic performance of knowledge workerbusinesses – improving agility, reducingcycle times, improving productivity andefficiency in technology development.

He has 25+ years experience in the softwareindustry starting with computer games in theearly 1980’s. He has led software teams

delivering superior productivity and quality usinginnovative agile methods. He developed MSF for CMMI Process Improvement for Microsoft.He is a co-author of the SEI Technical Note,CMMI and Agile: Why not embrace both!

David’s book, Agile Management for SoftwareEngineering – Applying the Theory of Constraints for Business Results , introducedmany ideas from Lean and Theory ofConstraints into software engineering.

David was a founder of the Lean Software &Systems Consortium, a not for profit dedicatedto promoting better standards of professionalismand effectiveness in software engineering.Email… [email protected]

Documents

Predictability & Measurement with Kanban