Key note - Lean Kanban Central Europe 2012 - Managing a Risky Business - Understanding Liquidity in Flow

Managing a Risky Business
Understanding Liquidity in
Flow

A proposed approach to
comparative assessment of
(software) service providers
using Kanban
Lean Kanban Central Europe,
Vienna, October 2012

dja@djaa.com, @agilemanager

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


Commitment in Kanban
Pool
of
Ideas

Engineering
Ready

Ongoing

2

Testing

Development

3

Done

3

Verification Acceptance

Deployment
Ready
∞

Pull

F

D

G

P1

E

PB

I

GY

DE

MN
AB

We are committing to getting
started with a probabilistic
expectation of delivery time

1st Commitment point

Done

2nd Phase Delivery Commitment
Pool
of
Ideas

Engineering
Ready

2

Testing

Development
Ongoing

3

Done

F

3


D
PB

∞

MN

G
DE

Deployment
Ready

P1

E
AB

I
GY

We are now committing to a
specific deployment and
delivery date

2nd Commitment point

Done

Defining Lead & Cycle Time
Pool
of
Ideas

Engineering
Ready

2

Pull

Deploy-

The clock starts ticking when
ment
Testing
we
Development accept the customers
Ready
3
3 order, not when it is placed!

Ongoing

Done

∞ queue.

Cycle time is an ambiguous term. It
must
D
This provides theP1correct be qualified, for example,
Development Cycle Time
G result for Little’s Law and

E

I

∞

Until then customer orders are
merely available options
Lead time ends when the item
reaches the first

F


Done

PB
visualization on a Cumulative
End-to-end Cycle Time = Time from 1st
GY
DE
MN
Flow Diagram
AB
commitment to delivery

Lead Time

Cycle Time
Cycle Time

Little’s Law

=

Delivery Rate

Pool
of
Ideas

WIP
Lead Time

Avg. Lead Time
WIP


Ready
To
Deploy

Avg. Delivery Rate

Infinite Queues Decouple Systems
Pool
Enginof
eering
The infinite queue Development
decouples
Ideas
Ready

the systems. The deployment
3 Done
Ongoing
system uses batches and is
2
separate from the kanban
system

F
The 2nd commitment is
actually a commitment for
PB
the downstream deployment
system
DE

Deployment
Ready

Testing

3


D

∞

MN

G

P1

E
AB

The Kanban System gives us
confidence to make that
I
downstream commitment
GY

2nd Commitment point

Done

Identifying Buffers
Pool
of
Ideas

Engineering
Ready

Ongoing

2

F

GY

3

Done

verification Acceptance

I am a buffer!
P1

PB

I

3

D

G

Testing

Development

Deployment
Ready

DE

The clue isis in my name “…
The clue in my name – –
E
Ready”
“… Ready”
MN
AB

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


∞

Done

Some Options Get Discarded
Pool
of
Ideas

Engineering
Ready

Ongoing

2

Testing

Development

3

3

Done


Deployment
Ready
∞

Pull

F

D

G

P1

The discard rate can be as
Emuch as 50%

PB
GY

DE

Reject
Discarded

I

MN
AB
have value

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

Done

Flow the
Efficiency
Flow efficiency measures

Pool
Enginpercentage of total lead time
of spent actually adding value
eering
is
Development
Ideas
Ready

(or knowledge) versus waiting
3
Ongoing

2

Done

Testing

3


Deployment
Ready
∞

Until then customer orders are
merely available options
Flow efficiency = Work Time

E

PB
GY

DE

Waiting Working

x 100%

Lead Time

Flow efficiencies of 2% have been
F
reported*. 5% -> 15% D normal, P1
is
>
40% is good!
G

I

Done

MN
AB

Waiting

Working Waiting

Lead Time
* 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
3.5
3

CRs & Bugs

2.5
2
1.5
1
0.5

1

4

7

0

3

6

8
14

14

13

12

12

11

10

99

92

85

78

71

64

57

50

43

36

29

22

8

15

1

0

Days

This is multi-modal data!
The workexpectation of
SLA is of two types:
Change Requests (new
105 and Production
features);days with 98 %
Defects

Mean of 31
days

SLA expectation of
44 days with 85% on-time

on-time

Mean
5 days

Change Requests

Production Defects

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

98% at
25 days
85% at
10 days


98% at
150 days

Mean
50 days

85% at
60 days

Allocate Capacity to Types of Work
Pool
of
Ideas

Engineering
Ready

Ongoing

2
Change
Requests

Development

4

3

Done

Testing

3


Consistent capacity allocation
E
some consistency to
should bring more consistency to
MN
delivery rate of work of each
D
AB
type

F

Lead Time

PB
DE
Productio
n
Defects

I

Deployment
Ready

3

G

P1

GY

Separate understanding of
Separate understanding of Lead
Lead Time for each type of
Time for each type of work
work
Lead Time


∞

Done

Psychology of
Probabilistic versus Deterministic
Approaches


Change Requests

The psychology of a probabilistic approach
can be challenging…

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

98% at
150 days
85% at
60 days


Classes of Service Help Improve Trust
Engineering
Ready

2

Development
Ongoing

3

Testing

3

Done


Different distributions for
different classes of service
Expedite 1
increases the level of trust that
an item will be delivered in a
AB
timely manner
Fixed
Date

2

P1

E

D

MN

PB
Standard

3

F

G

GY
Intangible

1

I

DE

Deployment
Ready
∞

Done

A lack of organizational social capital…
A lack of organizational social capital may
prevent trust in the kanban system from
There isemerging. The result is a degeneration to a
a trust in individual people rather than
the system. Individuals are held system.
deterministic accountable via
their commitments.
Everything must have an estimate. Plans are
Deterministic planning means a high likelihood
drawn deterministically. Overhead and rework
of incurred as things
(of plans) isbroken promises. change. Early and
specific commitments are requested
People take the blame!


…replace trust with comfort & reassurance

Deterministic planning provides a level of
comfort. Deterministic plans seem accurate and
When people take the blame, replacing the
plausible.
people provides a level of comfort that
remedial action has been taken.
When promises are broken it further
undermines the in a vicious cycle of
The organization is caughtsocial capital in the
organization.
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…
But can we view kanban systems as

Investment bankers know how to answer this
markets orders in liquid
question! They prefer to placefor software
markets. In a highly liquid market they have
development?
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.


Liquidity in the housing market
Sellers

$100

Bank

Buyers

Cash
$100


Measuring Liquidity
The more transactions, the more
liquid the market
what is required are well matched buyers,
sellers and access to capital such as mortgages,
Market liquidity is measured
bridging loans or cash buyers injecting capital
into the system, to fund the transactions .
transaction volume
when these conditions are present transactions
will take place!


as

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
Hence, market grow and few
matched buyers inventory will liquidity can be
transactions will happen.rate of transactions
measured as Uncertainty will
develop over the correctconcluded! trust
price. A lack of
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


Thinking of Kanban Systems
as 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
Pool
of
Ideas

Engineering
Ready

2

F

Development
Ongoing

3

Done

Testing

3


Deployment
Ready
∞

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
No Pull
act of pulling is the indicator that an item of
Workwork was matched to available workers and
flows through a kanban system when we
have well matched work order or items of WIP
flow happened.
with suitable staff to add valuable new
G
D
knowledge and progress work E completion.
to

I


Done

Variety & Specialization increase WIP
Pool
of
Ideas
∞

K

L

As a
DeployEngin- result, there will be a minimum level of
WIP
ment
eering required to facilitate flow. For systems
Testing
Development
with inherent liquidity problems - lots Ready
of
Ready
4

5 Done
heterogeneity in work types or variance in
Ongoing
4
∞
demand for quality (non-functional
requirements) and|or lots of specialists
workers, non-instant availability problems or
No Pull
J variability in skill and experience of
workers, then the WIP in the system will need
More WIP increases liquidity & freely.
to be larger in order for work to flow
The liquidity measure will not rise until the
G
increase flow!
D
E
WIP rises.

And Cost!

I
F

Pull
Pull


Done

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 spread
Immediacy - how quick an order is filled
Breadth - ability to handle large orders
Depth - processing orders at different
prices
Resiliency - 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 handled
Depth – 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 order
Some 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


Observed
Capability

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 global
Liquidity is ametric… system
measure.
Simple
Self-generatingup should not cause
Driving it
Relevant optimization or undesired
local
Leading Indicator
consequences!


Observed
Capability

What Next?...


Field study to test its effectiveness is
now needed
Highly liquid
What is required now is to correlate
liquidity measures with lead time
distributions and flow efficiency
measures.
What we would expect to see is
Why is this narrower
higher flow efficiency andimportant?
spreads of variability in lead times


systems should
exhibit
narrower
spread

Relevance of Liquidity as a Measure
Little’s Law

So our plans carry less
buffer for variation
Narrow spread of variation in lead
And
time for a fixed WIP means a more
predictable delivery rate. This is
Our planning horizons
turn means greater predictability on
delivery date for a given volume
be shorter!
of work and therefore a more
accurate price.


can

Conclusions


Building Liquidity Builds Trust in the
System
Highly liquid
Measuring and reporting system
liquidity is important to building
trust to enable a probabilistic
approach to management of
Highly liquid markets
knowledge work and hence
elimination of wasteful economicmanage
provide the trust to
overheads facilitating the comfort
probabilistically!
mechanisms inherent in the existing
pseudo-deterministic approach to
management.


systems should
exhibit
narrower
spread

Liquid Kanban Systems are Lean and
Agile Kanban Systems Highly liquid
System liquidity provides an
important indicator, solving the
governance challenge of selecting the
"Go Lean" and improve
best vendor or department to
agility by creating a highly
process a work order.

liquid system for
flowing work!


systems should
exhibit
narrower
spread

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


Liquidity in the housing market
Sellers


$100

Bank

Buyers

Fixed Date

Intangible

Standard

Expedite

Example Distributions


Key note - Lean Kanban Central Europe 2012 - Managing a Risky Business - Understanding Liquidity in Flow

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Key note - Lean Kanban Central Europe 2012 - Managing a Risky Business - Understanding Liquidity in Flow

Similar a Key note - Lean Kanban Central Europe 2012 - Managing a Risky Business - Understanding Liquidity in Flow (20)

Más de David Anderson

Más de David Anderson (13)

Último

Último (20)

Key note - Lean Kanban Central Europe 2012 - Managing a Risky Business - Understanding Liquidity in Flow