lean kanban netherlands 2012 - lean risk management

[email protected], @agilemanager

Lean Risk ManagementOptions, Liquidity & Hedging Risk using Kanban Systems


Making Promises with Kanban(and some often poorly understood fundamentals)


Commitment in Kanban

Done

Poolof

Ideas

F

H E

C A

I

Engin-eeringReady

Deploy-mentReady

GD

GYPB

DEMN

2 ∞

P1

AB

1st Commitment point

We are committing to getting started with a probabilistic

expectation of delivery time

Pull

Ongoing

Development Testing

Done VerificationAcceptance3 3


2nd Phase Delivery Commitment

Done

Poolof

Ideas

F

H E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

GY

PB

DE

MN

2 ∞

P1

AB

2nd Commitment point

We are now committing to a specific deployment and delivery

date

Kanban uses

2 Phase Commit

Ongoing

Development Testing



Defining Lead & Cycle Time

Done

Poolof

Ideas

F

H E

C A

I

Engin-eeringReady

Deploy-mentReady

GD

GYPB

DEMN

2 ∞

P1

AB

Pull

Lead Time

Ongoing

Development Testing


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

when it is placed!

Until then customer orders are merely available options

Lead time ends when the item

reaches the first ∞ queue.

This provides the correct result for Little’s Law and visualization on a Cumulative Flow Diagram

Cycle Time

Cycle time is an ambiguous term. It must be qualified, for example,

Development Cycle Time

End-to-end Cycle Time = Time from 1st commitment to delivery

Cycle Time


Delivery Rate

Lead Time

WIP=

Avg. Lead Time

Avg. Delivery Rate

WIP

Poolof

Ideas

ReadyTo

Deploy

Little’s Law


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


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

Done

Poolof

Ideas

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


ChangeRequest

s

Production

Defects

Separate understanding ofLead Time for each type of work

4

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


Risks & Qualitative Assessment


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 – for conversion from

options into real value.

Pull Selection is choosing from immediate options – ideally dynamic selection of the item with the

most immediate risk attached to it


Lean Risk Management uses Qualitative Assessment

But how do we determine the risks in a work item that we must

manage? We need a fast, cheap, accurate, consensus

forming approach to risk assessment. We need Lean Risk Management!

The answer is to use a set of qualitative methods to assess different dimensions of risk such as

urgency


Establish cost of delay (or urgency) by qualitative matching

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


Risk is a multi-dimensional problem

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


Classes of Service Manage Cost of Delay Risk

Done

FH

E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

GY

PB

MN

2 ∞

P1AB

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

DE


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


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

GrowthPotential

High

Low

High


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


Qualitative Taxonomies2 -> 6 categories

CheapFast

AccurateConsensus

Managed Risk

HeterogeneousExpensive

Time ConsumingFake Precision?

May still beHigh Risk

HomogenousCheapFastHigh Risk

A middle-ground in effective Risk Management

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


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.


Hedging


Hedging Delivery Risk with Capacity Allocation

Done

FH

E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

GY

PB

MN

2 ∞

P1AB

Ongoing

Development Testing


Expedite 1

3

Fixed Date

Standard

Intangible

2

3DE


Aligning with Strategic Position or Go-to-Market Strategy

Done

F

H

E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

GY

PB

MN

2 ∞

P1AB

Ongoing

Development Testing


Table Stakes 3

1

Cost Reducer

s

Spoilers

Differentiators

2

1DE

DA

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


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


Options


Some Options Get Discarded

Done

Poolof

Ideas

F

H E

C A

I

Engin-eeringReady

Deploy-mentReady

GD

GYPB

DEMN

2 ∞

P1

AB

Pull

The discard rate can be as much as 50%

Options have value because the future is uncertain

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

Discarded

Ongoing

Development Testing


Reject


Bottleneck should always be downstream of the commitment point

Poolof

Ideas

F

H E

C A

I

Engin-eeringReady

GD

GYPB

DEMN

2

P1

AB

Pull

Discarded

Ongoing

Analysis Testing


Reject

Ongoing

Development

Done3

Bottleneck should be here

Bottleneck workers should never be asked to work on something that is optional and may be

discarded. This includes any risk analysis (or estimation in legacy processes) that may be

required to assess viability of an option

Commitment point


Competing pressure of Last Responsible Moment versus Upstream Bottleneck

Poolof

Ideas

F

H E

C A

Engin-eeringReady

GD

GYPB

DEMN

2

P1

AB

Ongoing

Analysis Testing

Done VerificationAcceptance3 3Ongoing

Development

Done3

Commitment point

Last Responsible Moment Bottleneck early in workflow

Keeping the bottleneck early in the workflow means all downstream functions have slack

capacity. Reduces our need to manage WIP and reduces negative effects of variability in demand

In domains with high uncertainty the bottleneck should be

deliberately late in the workflow. We should be prepared to discard options very late.

Consider Lean Startup?...

Where is the bottleneck?


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


Liquidity


Where is the best place to place a work order to best manage risk?

Investment bankers know how to answer this question! They prefer to place orders in liquid

markets. In a highly liquid market they have trust that an order will be fulfilled accurately, quickly

and at the correct price.

Highly liquid markets are markets with a high level of trust. High liquidity inherently gives us high

confidence in the market.

But can we view kanban systems as markets for software

development?


Liquidity in the housing market

Sellers BuyersBank

$100

$100

Cash


Measuring Liquidity

what is required are well matched buyers, sellers and access to capital such as mortgages, bridging

loans or cash buyers injecting capital into the system, to fund the transactions .

when these conditions are present transactions will take place!

The more transactions, the more liquid the market

Market liquidity is measured as transaction volume


Adverse Market Conditions

In a market with lots of buyers but few well matched sellers, inventory will be scarce, few transactions will occur. When a property comes on the market it could sell quickly but there will be anxiety over the correct price. This may delay the sale or cause the buyer to

overpay through fear of losing the purchase to competitive buyers. In some markets like England,

the seller may refuse to close the transaction in hope of a higher price (gazumping).

Lack of liquidity causes a lack of trust in the system and delays transactions


More Adverse Market Conditions

In a market with lots of sellers but few well matched buyers inventory will grow and few

transactions will happen. Uncertainty will develop over the correct price. A lack of trust will result in a disparity between asked prices and offered prices. Additional information may be sought to establish

a fair price. Transactions will be delayed

Hence, market liquidity can be measured as rate of transactions

concluded!


So, how would we measure liquidity?


Measuring Real Liquidity…

If we recall, liquidity is measured as transaction volume in the market. So what are the transactions in a kanban

system?


Pull Transactions in Kanban

Done

Poolof

Ideas

F

H

E

C A

I

Engin-eeringReady

Deploy-mentReady

GD

2 ∞

No Pull

Ongoing

Development Testing


Work flows through a kanban system when we have well matched work order or items of WIP with

suitable staff to add valuable new knowledge and progress work to completion.

For work to flow freely in a kanban system, we must have work available to pull and suitably

matched workers available to pull it. Hence, the act of pulling is the indicator that an item of work

was matched to available workers and flow happened.


Variety & Specialization increase WIP

Done

Poolof

Ideas

F

H

E

C A

I

Engin-eeringReady

Deploy-mentReady

GD

4 ∞

No Pull

Ongoing

Development Testing


J

L

K

As a result, there will be a minimum level of WIP required to facilitate flow. For systems with

inherent liquidity problems - lots of heterogeneity in work types or variance in demand for quality

(non-functional requirements) and|or lots of specialists workers, non-instant availability

problems or variability in skill and experience of workers, then the WIP in the system will need to

be larger in order for work to flow freely. The liquidity measure will not rise until the WIP rises.

Pull

∞

More WIP increases liquidity & increase flow!

Pull

And Cost!


Liquidity is measured as volume of pull transactions

Thus, I am proposing that system liquidity be measured as the volume of pull transactions happening in a given

time period.


Normalizing Liquidity Measures

To normalize this figure across multiple systems, we could divide it

by the number of workers involved, or the (fixed) cost of running each

system over a time period. This would give us

pull transactions/person

Or,

pull transactions/€


Pull Transactions / Person

Greater values for pull transaction volume serve to show us the most

trustworthy system.

They represent the system most likely to offer the most predictable results.


Characteristics of Liquid Markets

A liquid financial market would exhibit several characteristics…

Tightness – bid-ask spreadImmediacy - how quick an order is filledBreadth - ability to handle large ordersDepth - processing orders at different pricesResiliency - ability of the market to swing back to normal or adjust after a surge in orders off the market or one large order that moves the price....


Characteristics of a Liquid Kanban Market

A liquid kanban system would exhibit these characteristics…

Tightness* – variance between customer expectations and probability of meeting it within current lead time capability (Due Date Performance???)Immediacy – flow efficiency or waiting time until pull**Breadth – variety of types of work handledDepth – variety of risks under management (and depth of taxonomies)Resiliency - ability of the system to recover to normal or adjust after a surge in orders breaching WIP constraints or swarming on expedite orders…

* Is this even relevant without a market maker?** Some work still required to determine whether time blocked should be included or not


Liquidity of the system should be considered against observed capability

before placing an orderSome kanban systems may appear faster and cheaper but carry more inherent risk as they have poorer

liquidity, handle less variety, are less resilient (can’t cope with or recover from

burst traffic)

Slightly longer to deliver but with greater certainty may be preferable to a system

with a lower average lead time but poorer liquidity & greater risk

ObservedCapability


Liquidity is a Good Metric

Our measure of liquidity, as pull transaction volume per person or unit of currency in a time period, meets Donald Reinertsen’s criteria for a useful metric…

SimpleSelf-generatingRelevantLeading Indicator

ObservedCapability

Liquidity is a global system measure.

Driving it up should not cause local optimization or undesired

consequences!


Relevance of Liquidity as a MeasureLittle’s Law

Narrow spread of variation in lead time for a fixed WIP means a more

predictable delivery rate. This is turn means greater predictability on

delivery date for a given volume of work and therefore a more accurate

price.

So our plans carry less buffer for variation

And

Our planning horizons can be shorter!


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!


Conclusions


Kanban enables new powerful approaches to risk management in

knowledge work

Kanban systems enable us to visualize many dimensions of real business risks.

Hedging risks is possible with capacity allocation in the system

Kanban is enabling the practical application of real option theory and

related concepts like real liquidity


Lean Risk Management is Pragmatic

Qualitative approaches to risk assessment are fast, cheap and drive

consensus

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

Stop speculating about business value and ROI. Instead assess real risks

and design kanban systems to manage them!


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 is published in June 2012, Lessons in Agile Management – On the Road to Kanban.

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


Acknowledgements

Raymond Keating of CME Group in New Jersey has been instrumental as a collaborator on the ideas in this presentation.

Real liquidity emerged as an idea from discussions on real options theory with Chris Matts, Olav Maassen, Mike Burrows and Julian Everett over a period totaling greater than six years.

Some final refinement of the concepts came about as a consequence of a conversation with Jon Jagger in October 2012.


David J Anderson& Associates, Inc.


Appendix


Identifying Buffers

Done

Poolof

Ideas

F

H E

C A

I

Engin-eeringReady

Deploy-mentReady

GD

GYPB

DEMN

2 ∞

P1

AB

Ongoing

Development Testing

Done verificationAcceptance3 3

I am a buffer!

The clue is in my name – “… Ready”

I am buffering non-instant availability or activity with a

cyclical cadence

I am a buffer!

The clue is in my name – “… Ready”

I am buffering non-instant availability or an activity with a

cyclical cadence


Infinite Queues Decouple Systems

Done

Poolof

Ideas

F

H E

C

A

I

Engin-eeringReady

Deploy-mentReady

G

D

GY

PB

DE

MN

2 ∞

P1

AB

2nd Commitment point

2nd Commitment

is for deployment

Ongoing

Development Testing


The infinite queue decouples the systems. The deployment system uses batches and is separate from the kanban

system

The 2nd commitment is actually a commitment for the

downstream deployment system

The Kanban System gives us confidence to make that

downstream commitment


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!


A lack of organizational social capital…

A lack of organizational social capital may prevent trust in the kanban system from emerging. The

result is a degeneration to a deterministic system.

Everything must have an estimate. Plans are drawn deterministically. Overhead and rework (of

plans) is incurred as things change. Early and specific commitments are requested

There is a trust in individual people rather than the system. Individuals are held accountable via their

commitments.

Deterministic planning means a high likelihood of broken promises.

People take the blame!


…replace trust with comfort & reassurance

Deterministic planning provides a level of comfort. Deterministic plans seem accurate and plausible.

When promises are broken it further undermines the social capital in the organization.

When people take the blame, replacing the people provides a level of comfort that remedial action

has been taken.

The organization is caught in a vicious cycle of distrust, individual commitment, disappointment,

blame and repercussions!



Sellers BuyersBank

$100



Sellers BuyersBank

$100

$100

Cash


Example Distributions

Sta

ndardE

xpedit

e

Inta

ngib

le

Fixe

d D

ate

lean kanban netherlands 2012 - lean risk management

Business