Lean Kanban Netherlands 2012 - Lean Risk Management

dja@djaa.com, @agilemanager

Lean Risk ManagementOptions, Liquidity & Hedging Risk using Kanban Systems

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

Commitment in Kanban

Poolof

Engin-eeringReady

Deploy-mentReady

1st Commitment point

We are committing to getting started with a probabilistic

expectation of delivery time

Ongoing

Development Testing

Done VerificationAcceptance3 3

2nd Phase Delivery Commitment

Poolof

Engin-eeringReady

Deploy-mentReady

2nd Commitment point

We are now committing to a specific deployment and delivery

Kanban uses

2 Phase Commit

Ongoing

Development Testing

Defining Lead & Cycle Time

Poolof

Engin-eeringReady

Deploy-mentReady

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

Avg. Lead Time

Avg. Delivery Rate

Poolof

ReadyTo

Deploy

Little’s Law

Flow Efficiency

Poolof

Engin-eeringReady

Deploy-mentReady

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

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

85% at60 days

Mean 50 days

98% at150 days

Lead Time

Allocate Capacity to Types of Work

Poolof

Engin-eeringReady

Deploy-mentReady

Separate understanding of Lead Time for each type of work

Ongoing

Development Testing

ChangeRequest

Production

Defects

Separate understanding ofLead Time for each type of work

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

Poolof

Engin-eeringReady

Deploy-mentReady

4 ∞Ongoing

Development Testing

KI have 4 options, which one

should I choose?

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

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

Risk is a multi-dimensional problem

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

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

Engin-eeringReady

Deploy-mentReady

Ongoing

Development Testing

Expedite 1

Fixed Date

Standard

Intangible

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

Cost of Delay has a 2nd Dimension

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

Working capital

Market Risk of Change

Highly likely to change

Highly unlikely to

change

StartEarly

StartLate

Differentiators

Spoilers

Table Stakes

Cost Reducers

Potential Value

ProfitsMarket Share

RegulatoryChanges

Product Lifecycle Risk

Investm

Not well understoodHigh demand for innovation &

experimentation

Well understoodLow demand for

innovation

Innovative/New

Major Growth Market

Cash Cow

GrowthPotential

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

Market Risk

Lifecycle

Cost of Delay

Tech Risk

Delay Impact

CowMid

Expedite

Intangible

Maj. Cap.

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

Engin-eeringReady

Deploy-mentReady

Ongoing

Development Testing

Expedite 1

Fixed Date

Standard

Intangible

Aligning with Strategic Position or Go-to-Market Strategy

Engin-eeringReady

Deploy-mentReady

Ongoing

Development Testing

Table Stakes 3

Cost Reducer

Spoilers

Differentiators

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%

Projects-in-progress

Horizational position shows percentage complete

Complete0%

Complete100%

Color may indicate cost of delay (or other risk)

Hedging Risk in a Portfolio Kanban

Options

Some Options Get Discarded

Poolof

Engin-eeringReady

Deploy-mentReady

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

Engin-eeringReady

Discarded

Ongoing

Analysis Testing

Reject

Ongoing

Development

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

Engin-eeringReady

Ongoing

Analysis Testing

Done VerificationAcceptance3 3Ongoing

Development

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

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

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

Poolof

Engin-eeringReady

Deploy-mentReady

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

Poolof

Engin-eeringReady

Deploy-mentReady

No Pull

Ongoing

Development Testing

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.

More WIP increases liquidity & increase flow!

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

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

Our planning horizons can be shorter!

Table Stakes 3

Cost Reducer

Spoilers

Differentiators

Improving Liquidity through Labor Pool Flexibility

Engin-eeringReady

Ongoing

Analysis Testing

Done VerificationAcceptance3 3Ongoing

Development

Steven

Rhonda

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!

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

Poolof

Engin-eeringReady

Deploy-mentReady

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

Poolof

Engin-eeringReady

Deploy-mentReady

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

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

Example Distributions

ndardE

xpedit

Lean Kanban Netherlands 2012 - Lean Risk Management

Business

Jit (us), kanban, lean

Lean Software Development - Net Objectives · with, Lean-Kanban University kanban Kanban LKU Kanban ... Kanban as a Team Development Process Often reducing batch size is all it takes

Joachim Pfeﬀ er Basiswissen zu Scrum, Kanban, Lean ... · Basiswissen zu Scrum, Kanban, Lean Development peppair Verlag Basiswissen zu Scrum, Kanban, Lean Development Agile Arbeitsweisen

Lean, Kanban and TFS

Lean Software Development & Kanban

Lean Kanban FR 2013 - Vin et kanban

Scrum with Kanban: Lean Kanban Russia 2014

Lean Kanban to Lean Business

Lean Kanban Practitioner

Lean, Kanban & Management Visuel - idl.pepi.inra.fridl.pepi.inra.fr/attachments/article/34/r96_9_at2011-prez-lean... · Lean, Kanban & Management Visuel Eric Colin, Christine Chevrier,

How to start my kanban - Lean Kanban France 2015

Lean Kanban France2013 : kanban for managers

Lean kanban y Productividad

Lean , Pull System & Kanban |iZenBridge

Kaizen kanban-lean manufacturing

Jpk lean kanban-gezondheidszorg

Lean kanban

Lean / Kanban

Lean, Kanban, and TFS

Inside Lean Kanban (#lkuk14 keynote)