Using Kanban to improve Risk Management inside creative knowledge worker industries. This talk takes a first look kanban system liquidity as a measure of predictability and reliability of service delivery. [The liquidity section of this talk was updated and improved at Lean Kanban North America 2013]
Falcon Invoice Discounting: Empowering Your Business Growth
Key note - Lean Kanban Central Europe 2012 - Managing a Risky Business - Understanding Liquidity in Flow
1. 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
2. Making Promises with Kanban
(and some often poorly understood fundamentals)
dja@djaa.com, @agilemanager
4. 2nd Phase Delivery Commitment
Pool
of
Ideas
Engineering
Ready
2
Testing
Development
Ongoing
3
Done
F
3
Verification Acceptance
D
PB
∞
MN
G
DE
Deployment
Ready
P1
E
AB
I
GY
We are now committing to a
specific deployment and
delivery date
dja@djaa.com, @agilemanager
2nd Commitment point
Done
5. 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
Verification Acceptance
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
dja@djaa.com, @agilemanager
7. 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
Verification Acceptance
D
∞
MN
G
P1
E
AB
The Kanban System gives us
confidence to make that
I
downstream commitment
GY
2nd Commitment point
dja@djaa.com, @agilemanager
Done
8. 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
dja@djaa.com, @agilemanager
∞
Done
9. Some Options Get Discarded
Pool
of
Ideas
Engineering
Ready
Ongoing
2
Testing
Development
3
3
Done
Verification Acceptance
Deployment
Ready
∞
Pull
F
D
G
P1
The discard rate can be as
Emuch as 50%
PB
GY
DE
Reject
Discarded
I
dja@djaa.com, @agilemanager
MN
AB
have value
Options
because the
future is uncertain
0% discard rate implies there
is no uncertainty about the
future
Done
10. 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
Verification Acceptance
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
dja@djaa.com, @agilemanager
11. 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
dja@djaa.com, @agilemanager
on-time
12. 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
dja@djaa.com, @agilemanager
98% at
150 days
Mean
50 days
85% at
60 days
13. Allocate Capacity to Types of Work
Pool
of
Ideas
Engineering
Ready
Ongoing
2
Change
Requests
Development
4
3
Done
Testing
3
Verification Acceptance
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
dja@djaa.com, @agilemanager
∞
Done
15. 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
dja@djaa.com, @agilemanager
16. Classes of Service Help Improve Trust
Engineering
Ready
2
Development
Ongoing
3
Testing
3
Done
Verification Acceptance
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
dja@djaa.com, @agilemanager
DE
Deployment
Ready
∞
Done
17. 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!
dja@djaa.com, @agilemanager
18. …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!
dja@djaa.com, @agilemanager
20. 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!
dja@djaa.com, @agilemanager
21. 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.
dja@djaa.com, @agilemanager
22. Liquidity in the housing market
Sellers
$100
Bank
Buyers
Cash
$100
dja@djaa.com, @agilemanager
23. 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!
dja@djaa.com, @agilemanager
as
24. 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
dja@djaa.com, @agilemanager
25. 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
dja@djaa.com, @agilemanager
27. 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).
dja@djaa.com, @agilemanager
28. So, how would we measure
liquidity?
dja@djaa.com, @agilemanager
29. Measuring Real Liquidity…
If we recall, liquidity is measured as
transaction volume in the market. So
what are the transactions in a kanban
system?
dja@djaa.com, @agilemanager
30. Pull Transactions in Kanban
Pool
of
Ideas
Engineering
Ready
2
F
Development
Ongoing
3
Done
Testing
3
Verification Acceptance
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
dja@djaa.com, @agilemanager
Done
31. 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
Verification Acceptance
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
dja@djaa.com, @agilemanager
Done
33. 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.
dja@djaa.com, @agilemanager
34. 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/€
dja@djaa.com, @agilemanager
35. 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.
dja@djaa.com, @agilemanager
36. 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....
dja@djaa.com, @agilemanager
37. 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
dja@djaa.com, @agilemanager
38. 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
dja@djaa.com, @agilemanager
Observed
Capability
39. 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!
dja@djaa.com, @agilemanager
Observed
Capability
41. 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
dja@djaa.com, @agilemanager
systems should
exhibit
narrower
spread
42. 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.
dja@djaa.com, @agilemanager
can
44. 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.
dja@djaa.com, @agilemanager
systems should
exhibit
narrower
spread
45. 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!
dja@djaa.com, @agilemanager
systems should
exhibit
narrower
spread
47. 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.
dja@djaa.com, @agilemanager
48. 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.
dja@djaa.com, @agilemanager