key note - lean kanban central europe 2012 - managing a risky business - understanding liquidity in...

dja@djaa.com, @agilemanager

Managing a Risky Business Understanding Liquidity in Flow

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

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

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

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

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

Psychology ofProbabilistic versus Deterministic

Approaches

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!

Classes of Service Help Improve Trust

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

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!

The Big Organizational Governance Question

How do you choose where to place a piece of work or project?

Which of these three departments is the best choice to do my project?

I want the best price, fastest delivery & highest quality!

Investment Bankers have an Answer…

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!

Thinking of Kanban Systemsas a Market

Revisiting , how to choose where to place a piece of work or project?

If we were to think of rival kanban systems as markets, then we'd have a solution to our governance problem.

Orders for new software should be placed in the most liquid market (or

kanban system).

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!

Defining Liquidity for Kanban Systems

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!

What Next?...

Field study to test its effectiveness is now needed Highly liquid

systems should exhibit narrower

spread

What is required now is to correlate liquidity measures with lead time distributions and flow efficiency

measures.

What we would expect to see is higher flow efficiency and narrower spreads

of variability in lead timesWhy is this important?

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!

Conclusions

Building Liquidity Builds Trust in the System Highly liquid

spread

Highly liquid markets provide the trust to

manage probabilistically!

Measuring and reporting system liquidity is important to building trust to enable a probabilistic approach to management of knowledge work and

hence elimination of wasteful economic overheads facilitating the comfort mechanisms inherent in the

existing pseudo-deterministic approach to management.

Liquid Kanban Systems are Lean and Agile Kanban Systems Highly liquid

spread

System liquidity provides an important indicator, solving the governance

challenge of selecting the best vendor or department to process a work order.

"Go Lean" and improve agility by creating a

highly liquid system for flowing work!

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

Sellers BuyersBank

Example Distributions

ndardE

xpedit

key note - lean kanban central europe 2012 - managing a risky business - understanding liquidity in...

Business

kanban != kanban board

speech reserve management and international …...

lean kanban fr 2013 - vin et kanban

the project kanban wall: combining kanban and scrum...

discovery kanban - lean kanban uk 2014

strength-based kanban (lean kanban france 2012 #lkfr12)

interbank market turmoils and the macroeconomy - nbp.pl ·...

kanban vs scrum - infoq.com · o kanban, rozprávanie o...

risky business - geoneurale · risky business r e (gene ...

lean software development - net objectives · with,...

kanban-logistik - nold.de · nold-kanban 2 was ist kanban?...

¡a todo kanban! ~ introducción a kanban

kanban - migrando do scrum para o kanban

kanban - how to coordinate with kanban

macroeconomic liquidity, bank liquidity, market liquidity

kanban steuerung - bwl-online —...

lean kanban france2013 : kanban for managers

industrie 4.0 ohne lean production...kanban logistisches...

kanban iceberg, lean kanban north america 2015 conference

providing risky play in ece...