delivering better predictability, business agility & governance with kanban

[email protected], @agilemanager

Delivering Better Predictability, Business Agility & Governancewith Kanban


Background


PM

Change requests

Microsoft 2004 - the XIT Story

Developers TestersProduct

Managers

User Acceptance

Deployment

1211

10

9

8

7

6

5

4

3

2

1

PrioritizedBacklog

76

5

9

4

3

2

1

Waiting forTest

11

1

PTCs

PTCs? What did that acronym mean? Items that did not require coding!

Why were they treated as emergencies?

Requests for estimates or analysis of future work are often “invisible”, have

an unpredictable arrival rate & are given priority.Emergency work is unplanned &

receives highest priority. Arrival rate & volume are unpredictable.

Effect is hugely disruptive!


Predictability, Agility & Governance


Managers

User Acceptance

Deployment

1211

10

9

8

7

6

5

4

3

2

1

PrioritizedBacklog

76

5

9

4

3

2

1

Waiting forTest

11

1

PTCsSo how were they doing on our

measures of predictability, agility & governance?

On-time delivery was 0%. There was a 100% chance of interruption to estimate future

work.

Planning & prioritization were conducted monthly. Fastest response from receipt to

deployment was around 6 weeks.

But everything had a business case and was prioritized by ROI!

So the drive for good governance was destroying predictability and agility!


What Were the Issues?


Managers

User Acceptance

Deployment

1211

10

9

8

7

6

5

4

3

2

1

PrioritizedBacklog

76

5

9

4

3

2

1

Waiting forTest

11

1

PTCsSo what issues affected the outcome?

Why were governance policies so disruptive?

Product managers demanded fast response on estimates to facilitate future planning and provide fast feedback to business owners.

Entire backlog was planned & commitments made early. 90% of the backlog was re-planned

each month.

Expedite policy for PTCs was folklore – no one could explain why

Process Improvement Conclusion Controlling unplanned, disruptive

demand would improve predictability!


A virtual kanban system was chosen

Backlog

D

E

A

I

Engin-eeringReady

G

5Ongoing

Development Testing

Done3 3

TestReady

5

PTCs

F

B

CPull

Pull

PTCs are permitted to break the kanban limit

*Blocked to service PTC

*

UAT

Deploy-mentReady

∞ ∞

H

FF

FFF

F F

G

Pull

ChangeRequests It’s important to realize the process for

software development did not change. The kanban system is an overlay on the existing process. It changes scheduling

and prioritization only


The Results

Time (in quarters)

CR

s

10

30

50

Backlog depleted. Serving at rate of

demand

240% improvement

in delivery rate

Time (in quarters)

Avera

ge

Tim

e t

o R

esolv

e

25

75

125

90% drop in end-to-end cycle time*

* Includes queuing time prior to selection


Robert Bosch* (2006-2008)IS Website Maintenance Results

Time (6 mth intervals)

Avera

ge

Tim

e t

o C

reate

to R

esolv

e

10

20

40

78% drop in end-to-end cycle time

* South Bend, Indiana


State of Virginia, Department of Corrections (2011-2012)

Time (3 mth intervals)

Avera

ge

Tim

e t

o C

reate

to R

esolv

e

10

20

40

58% drop in end-to-end cycle time


Understanding Kanban Systems


H

FF

FFF

F J

I

Pull

ChangeRequests

Kanban are virtual!

Backlog

D

E

A

I

Engin-eeringReady

G

5Ongoing

Development Testing

Done3 3

TestReady

5

PTCs

F

B

CPull

PullThese are the virtual kanban

*

These are the virtual kanbanThese are the virtual kanbanThese are the virtual kanban

The board is a visualization of the workflow process, the work-in-progress

and the (virtual) kanban

Boards are not required to do Kanban!

The first system used database triggers to signal pull. There was no board!

UAT

Deploy-mentReady

∞ ∞


Wish to avoid discard after commitment

Commitment is deferred

Backlog

H

E

C A

I

Engin-eeringReady

D

5Ongoing

Development Testing

Done3 3

TestReady

5

PTCs

Commitment point

We are committing to getting started. We are certain we want

to take delivery.

UAT

Deploy-mentReady

∞ ∞

FF

FFF

F F

G

Pull

ChangeRequests

Items in the backlog remain optional and unprioritized


Discard rates are often high

Backlog

H

E

C A

I

Engin-eeringReady

D

5Ongoing

Development Testing

Done3 3

TestReady

5

PTCs

UAT

Deploy-mentReady

∞ ∞

FF

F F

G

ChangeRequests

H

Discarded

The discard rate with XIT was 48%. ~50% is commonly observed.

Options have value because the future is uncertain

0% discard rate implies there is no uncertainty about the future

I

Reject

Deferring commitment and avoiding interrupting

workers for estimates makes sense when

discard rates are high!


FF

FFF

F F

Specific delivery commitment may be deferred even later

UATBacklog

H

E

C A

I

Engin-eeringReady

Deploy-mentReady

G

D

5∞

Pull

Ongoing

Development Testing

Done3 3

TestReady

5

PTCs

ChangeRequests

2nd

Commitmentpoint*

Kanban uses

2 Phase Commit

∞

Discarded

I

We are now committing to a specific deployment and delivery

date

*This may happen earlier if circumstances demand it


FF

FFF

F F

Replenishment Cadence

UATBacklog

H

E

C A

I

Engin-eeringReady

Deploy-mentReady

G

D

5∞

Replenishment

Ongoing

Development Testing

Done3 3

TestReady

5

PTCs

ChangeRequests

∞

Discarded

I

The frequency of system replenishment should reflect

arrival rate of new information and the transaction &

coordination costs of holding a meeting

Pull

Frequent replenishment is more agile.

On-demand replenishment is most

agile!


FF

FFF

F F

Delivery Cadence

UATBacklog

H

E

C A

I

Engin-eeringReady

Deploy-mentReady

G

D

5∞

DeliveryOngoing

Development Testing

Done3 3

TestReady

5

PTCs

ChangeRequests

∞

Discarded

I

The frequency of delivery should reflect the transaction &

coordination costs of deployment plus costs &

tolerance of customer to take delivery

Pull Deployment buffer size can reduce as frequency of delivery

increases

Frequent deployment is more agile.

On-demand deployment is most agile!


FF

FFF

F F

Defining Lead Time

UATBacklog

H

E

C A

I

Engin-eeringReady

Deploy-mentReady

G

D

5∞

Pull

Ongoing

Development Testing

Done3 3

TestReady

5

PTCs

ChangeRequests

∞

Lead Time

The clock starts ticking when we accept the customers order, not

when it is placed!

Until then customer orders are merely available optionsLead time (through

the kanban system) ends when the item

reaches the first ∞ queue.

This provides the correct result for Little’s Law and

visualization on a Cumulative Flow

DiagramDiscarded

I


Delivery Rate

Lead Time

WIP=

Mean Lead Time

Mean Delivery Rate

WIP

Backlog ReadyTo

Deploy

Little’s Law


Improving Agility


Factors Affecting Agility

The business agility of the system is determined by the replenishment cadence, the delivery cadence

and the lead time (or end-to-end cycle time) through the system.

Kanban decouples replenishment from lead time & delivery

enabling tailoring of the process to the dynamics of the business

domain


FF

FFF

F F

Benefits of Limiting WIP

UATBacklog

H E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

5∞

Pull

Ongoing

Development Testing

Done3 3

TestReady

5

PTCs

ChangeRequests

∞

Lead Time

Discarded

I

#*

Blocked!

*Specialist test environment unavailable

Bug

Blocked!

Defect found requiring coding fix

Limiting WIP reduces multi-tasking. Shortens lead time. Focuses

organization on impediment removal and limits due date performance

degradation from poor quality & rework


Observe Lead Time Distribution as an enabler of a Probabilistic Approach to Management

Lead Time Distribution

0

0.5

1

1.5

2

2.5

3

3.5

Days

CR

s &

Bu

gs

SLA expectation of44 days with 85% on-time

Mean of 31 days

SLA expectation of105 days with 98 % on-time

This is multi-modal data!

The work is of two types: Change Requests (new

features); and Production Defects

This is multi-modal data!

The work is of two types: Change Requests (new

features); and Production Defects


Filter Lead Time data by Type of Work (and Class of Service) to get Single Modal Distributions

85% at10 days

Mean5 days

98% at25 days

Change R

equest

s

Pro

duct

ion D

efe

cts

85% at60 days

Mean 50 days

98% at150 days


Lead Time

Lead Time

Allocate Capacity to Types of Work

DoneBacklog

F

H

E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

GY

PBDE

MN

2 ∞

P1

AB

Separate understanding of Lead Time for each type of work

Ongoing

Development Testing

Done VerificationAcceptance3 3

ChangeRequest

s

Production

Defects

Separate understanding ofLead Time for each type of work

5

3

Consistent capacity allocation should bring some consistency to delivery rate of work of each type

Consistent capacity allocation should bring more consistency to delivery rate of work of each type


Flow Efficiency

Done

Poolof

Ideas

F

H E

C A

I

Engin-eeringReady

Deploy-mentReady

GD

GYPB

DEMN

2 ∞

P1

AB

Lead Time

Ongoing

Development Testing


Flow efficiency measures the percentage of total lead time that is spent actually adding value (or knowledge) versus

waiting

Until then customer orders are merely available options

Waiting Waiting WaitingWorkingWorking

Flow efficiency = Work Time x 100%

Lead TimeFlow efficiencies of 2% have been reported*. 5% -> 15% is

normal, > 40% is good!

* Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012


Short lead time reduces chance of discard

FF

FFF

F F

Benefits of Reducing Lead Time

UATBacklog

H E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

5∞

Pull

Ongoing

Development Testing

Done3 3

TestReady

5

PTCs

ChangeRequests

∞

Discarded

I

Bug

Bug

Bug

Defect insertion rate increases non-linearly with long lead times

and low flow efficiency.

Defect fix times increase non-linearly with delay time from

discovery to fix

Short lead times enable later commitment, reduce likelihood of post-commitment discard or rework due to perishable nature of information and improve quality as defect insertion

rates fall non-linearly with reduced lead time


More Results (from 2005)

Time (in quarters)

Flow

Effi

cien

cy (

%)

15

45

75

Flow efficiency improved from

8% to 92%

Time (in quarters)

Due D

ate

Perf

orm

ance

15

45

75 DPP improved almost instantly from 0% to

98% against lead time SLA*

* Measured from point of commitment

These improvements were minimally intrusive, met with little to no resistance

(though some managerial derision) and cost almost nothing!

If it works this well, perhaps we should try this

again?!!


Ability to handle variety and heterogeneity of risks improves business performance

The kanban system explicitly exposes the business risks in terms of types of demand, quantity & rate of demand. It helps us to understand the costs & benefits of frequent interaction with upstream &

downstream functions. And it gives us a temporary and quantitative understanding of our capability to

deliver against demand

Kanban enables us to build a trusted delivery capability. Agility

and predictability are tuned to the inherent risks in the business

domain!


Risk Management


The psychology of a probabilistic approach can be challenging…

Change R

equest

s

85% at60 days

Mean 50 days

98% at150 days

I don’t want to take the risk of being longer than 60 days. I need a precise estimate of when it will

be delivered!


Cost of Delay is a critical business risk

time

impa

ct

time

time

time

impa

ctim

pact

impa

ct

time

impa

ct

time

impa

ctim

pact

Expedite – critical and immediate cost of delay; can exceed other kanban limit (bumps other work)

Fixed date – cost of delay goes up significantly after deadline; Start early enough & dynamically prioritize to insure on-time delivery

Standard - cost of delay is shallow but accelerates before leveling out; provide a reasonable lead-time expectation

Intangible – cost of delay may be significant but is not incurred until much later; important but not urgent

time

Qualitative approaches to risk management using taxonomies of 2 to 6 categories for

each dimension of risk have been shown to fast, cheap & effective in comparison to quantitative methods that often involve

speculation and false precision


Implementing Classes of Service

Done

FH

E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

2 ∞

P1

Ongoing

Development Testing


Expedite 1

3

Fixed Date

Standard

Intangible

2

1

Different distributions for different classes of service increases the level of trust that an item will be

delivered in a timely manner, demonstrating that cost of delay is

a risk under management


The Optimal Exercise Point

impa

ct

When we need it

85th percentile

Ideal StartHere

Commitment point

If we start too early, we forgo the option and opportunity to do something else that may

provide value.

If we start too late we risk incurring the cost of delay

With a 6 in 7 chance of on-time delivery, we can always

expedite to insure on-time delivery


Hedge Delivery Risk by spreading capacity across items of differing urgency

Done

FH

E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

2 ∞Ongoing

Development Testing


Expedite 1

3

Fixed Date

Standard

Intangible

2

3

Uncertainty in demand or arrival rate of urgent & critical items is offset with capacity for items that are easily delayed


Kanban improves risk management

Kanban systems should be designed to visualize the true business risks under

management.

Demand can be classified for multiple risks & analyzed for

arrival rate

Risk is a multidimensional problem.

Kanban enables many strategies for managing it, including hedging & aspects of real option theory eg deferred commitment, optimal

exercise point decision making; & system liquidity management.


Cost of Delay has a 2nd Dimension

time

impa

ct

time

impa

ct

time

impa

ctim

pact

Extinction Level Event – a short delay will completely deplete the working capital of the business

Major Capital – the cost of delay is such that a major initiative or project will be lost from next year’s portfolio or additional capital will need to be raised to fund it

Discretionary Spending – departmental budgets may be cut as a result or our business misses its profit forecasts

Intangible – delay causes embarrassment, loss of political capital, affects brand equity, mindshare, customer confidence, etc

time

?

Working capital

Working capital


Market Risk of Change

Mark

et

Ris

k

Sch

ed

ulin

g

Highly likely to change

Highly unlikely to

change

StartEarly

StartLate

Differentiators

Spoilers

Table Stakes

Cost Reducers

Potential Value

ProfitsMarket Share

etc

RegulatoryChanges


Aligning with Strategic Position or Go-to-Market Strategy

Done

F

H

E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

2 ∞Ongoing

Development Testing


Table Stakes 3

1

Cost Reducer

s

Spoilers

Differentiators

2

1

Market segmentation can be used to narrow the necessary table stakes for any given market niche!

Enabling early delivery for narrower markets but potentially including value generating

differentiating features


Product Lifecycle Risk

Pro

du

ct

Ris

k

Investm

en

t

Not well understoodHigh demand for innovation &

experimentation

Well understoodLow demand for

innovation

Low

Low

Innovative/New

Major Growth Market

Cash Cow

ProfitMargin

High

Low

High


ACash Cows10% budget

Growth Markets60% budget

Innovative/New30% budget

Allocation of personnelTotal = 100%

B

D

E

F

K

H

G

Projects-in-progress

Horizational position shows percentage complete

Complete0%

Complete100%

C

Color may indicate cost of delay (or other risk)

Hedging Risk in a Portfolio Kanban


Visualize Risks to provide Scheduling Information

TS

Market Risk

CR

Spoil

Diff

Lifecycle

Cost of Delay

Tech Risk

Delay Impact

CowMid

New

Expedite

FDStd

Intangible

ELE

Maj. Cap.

Disc

Unknown SolnKnown but not us

Done it beforeCommodity

Risk profile for a work item or deliverable

Outside:Start Early

Inside:Start Late

Items with the same shape carry the same risks and should be scheduled into the kanban system

at approximately the same time.

Do not prioritize items. From a group of items with the same risk profile pick whichever ones you like

or prefer most

It is also wise to hedge risk by allocating capacity in the system for items of different risk profiles.


Table Stakes 3

1

Cost Reducer

s

Spoilers

Differentiators

2

1

Improving Liquidity through Labor Pool Flexibility

Teams

F

HE

CA

Engin-eeringReady

G

D

GY

PBDE

MN

2

P1

AB

Ongoing

Analysis Testing

Done VerificationAcceptance3 3Ongoing

Development

Done3

Joe

Peter

Steven

Joann

David

Rhonda

Brian

Ashok

TeamLead

Junior who will be rotated through all 4 teams

Generalist or T-shaped people who can move flexibly across rows on the board to keep work

flowing

It’s typical to see splits of fixed team workers versus flexible system

workers of between 40-60%

Roughly half the labor pool are flexible workers

Promotions from junior team member to flexible

worker with an avatar clearly visualize why a

pay rise is justified. Flexible workers help manage liquidity risk

better!


Risk is a multi-dimensional contextual problem

These are just useful examples!

We must develop a set of risk taxonomies that work in context

for a specific business.

We can easily envisage other risk dimensions such as technical risk, vendor dependency risk, organizational maturity risk and so forth.

It may be necessary to run a workshop with stakeholders to explore and expose the real

business risks requiring management


Coping with Larger Deliverables


Cost of Delay attaches to a deliverable

So understanding cost of delay enables us to know what to pull

next?

Yes, however, it isn’t always relevant! Cost of delay attaches to a deliverable item. What if that

item is large? Whole projects, minimum marketable features (MMFs) or minimum viable products (MVPs) consist of many smaller items.

We need to understand the risks in those smaller items too, if we are to know how to schedule work,

replenish our system and make pull decisions wisely


Make a long term plan to build platform replacement

Device Management Ike II Cumulative Flow

020406080

100120140160180200220240

Time

Fe

atu

res

Inventory Started Designed Coded Complete

Slope in middle3.5x - 5x slope

at ends 5x

Required throughput (velocity)

2006 2008

During the middle 60% of the project schedule we need Throughput (velocity) to average 220 features

per month


Delivery Rate

Lead Time

WIP=

Little’s Law

From observed capability

Treat as a fixed variable

Targetto

achieve plan

Calculated based on known lead time

capability & required delivery

rate

Determines staffing level

Changing the WIP limit without maintaining the staffing level ratio represents a change to the way of

working. It is a change to the process and will produce a change in the observed ‘common cause’

capability of the system

Plan based on currently observed capability and current working

practices. Do not assume process improvements.

If changing WIP to reduce undesirable effects (e.g.

multitasking), get new sample data (perform a spike) to observe

the new capability


55/week

0.4 weeks

WIP = 22=

Using Little’s Law

From observed capability

Treat as a fixed variable

Targetto

achieve plan

Calculated based on known lead time

capability & required delivery

rate

Determines staffing level

At this point perhaps just a little black magic and experience may

be required.

Rounding 22 up to 25 would conveniently provide for 5 teams with a WIP limit of 5 items each

If our current working practices/process exhibited an

average WIP of 1 item per person then we require 25 people

organized in 5 teams of 5 people to complete the project on-time


1 lane per team


Lead time

WIP in this area should be 25

items*

*photo taken early in the project

before it was fully staffed/loaded

Median lead time target is 2 days

Alert managers if beyond 5 days


Definition of TheKanban Management Method


Kanban creates an evolutionary capability within your organization

Kanban systems have been shown to catalyze process evolution.

It is thought that the WIP limit provokes conversations &

encourages collaboration around changes

Kanban is a cultural & management approach to organizational

improvement founded on 4 principles

1. Start with what you do now2. Agree to pursue evolutionary change

3. Initially respect current roles, responsibilities & job titles

4. Encourage acts of leadership at all levels in your organization


Evolutionary capability protects a business from an uncertain future

An evolutionary capability is vital to coping with complexity and manage

the risk of “unknown unknowns.”

Kanban creates evolutionary capability through the use of 6

practices

Core Practices of the Kanban Method

1. Visualize2. Limit WIP

3. Manage Flow4. Make Policies Explicit

5. Create feedback loops (at workflow, management & organizational

levels)

6. Improve collaboratively, evolve experimentally (using models & the

scientific method)


Better Governance


Key Risk to Manage is “What to Pull Next?”

Done

Poolof

Ideas

F

H

E

CA

I

Engin-eeringReady

Deploy-mentReady

G

D

4 ∞Ongoing

Development Testing


J

L

KI have 4 options, which one

should I choose?

Pull

∞

Pull

SystemReplenishment

PullSelection

Replenishing the system is an act of commitment – selecting items for delivery. Committing to the

cost to convert from options into real value.

Pull Selection is choosing from immediate options – an act of dynamic prioritization of the item with

the most immediate risk attached to it


Continuous Improvement


Team-level Kaizen events happen naturally


Operations reviews drive inter-team kaizen events


The 5 Benefits of Kanban

Kanban is a “many-headed-hydra.” It helps us deal with simple, complicated

& complex problems

The wide utility of Kanban makes it broadly applicable in many

domains

Benefits of Using Kanban

1. Improved Predictability2. Better Business Agility

3. Better Governance4. Improved Risk

Management5. Evolutionary Capability

for resilience in the face of uncertainty


Conclusions


Kanban systems control variability that affect predictability

Kanban systems defer commitments improving quality of decision making and reducing unnecessary work and

rework.

Predictability is improved!

Committing early is comforting but can lead to disappointment later.

Kanban builds trust enabling deferred

commitment


Kanban enables improved agility

Replenishment & delivery cadences are de-coupled and can be tuned to

information arrival and overhead of the transaction.

Lead time can be independent of replenishment & delivery cadence!

Industries such as media require the decoupled dynamics of kanban to

react to unfolding events


Kanban Improves Governance

Visualization of the kanban system and explicit declaration of policies improves

transparency on risk management

There is no crystal ball gazing! Risk analysis is not speculative!

Kanban systems can be designed to align directly with strategic plans & go-

to-market strategies


Thank you!


About

David Anderson is a thought leader in managing effective software teams. He leads a consulting, training and publishing and event planning business dedicated to developing, promoting and implementing sustainable evolutionary approaches for management of knowledge workers.He has 30 years experience in the high technology industry starting with computer games in the early 1980’s. He has led software teams delivering superior productivity and quality using innovative agile methods at large companies such as Sprint and Motorola.

David is the pioneer of the Kanban Method an agile and evolutionary approach to change. His latest book published in June 2012 is, Lessons in Agile Management – On the Road to Kanban.

David is a founder of the Lean-Kanban University Inc., a business dedicated to assuring quality of training in Lean and Kanban for knowledge workers throughout the world.


Acknowledgements

A virtual kanban system was first used with an offshore team within Microsoft’s IT department in 2004/2005. The Kanban Method as it is known today emerged at Corbis 2006/2007.

Adoption of cumulative flow diagrams, Little’s Law, virtual kanban systems & cost of delay were heavily influenced by Donald Reinertsen.

Major contributors to the material in this presentation include Daniel Vacanti, Jim Benson, Corey Ladas, Janice Linden-Reed, Troy Magennis, Chris Matts, Olav Maassen and Julian Everett


David J Anderson& Associates, Inc.


Appendix


Example Distributions

Sta

ndardE

xpedit

e

Inta

ngib

le

Fixe

d D

ate

delivering better predictability, business agility & governance with kanban

Documents

endtoend cycle time

time delivery

queuing time

kanban toolbox

kanban limit

better predictability

measures of predictability

governance policies