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

[email protected], @agilemanager

Managing a Risky Business Understanding Liquidity in Flow


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


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


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


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


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


Psychology ofProbabilistic versus Deterministic

Approaches


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!


Classes of Service Help Improve Trust

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

DE


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

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


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

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!


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

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!


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

And

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!


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



Sellers BuyersBank

$100



Sellers BuyersBank

$100

$100

Cash


Example Distributions

Sta

ndardE

xpedit

e

Inta

ngib

le

Fixe

d D

ate