View
273
Download
0
Category
Preview:
DESCRIPTION
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]
Citation preview
dja@djaa.com, @agilemanager
Managing a Risky Business Understanding Liquidity in Flow
dja@djaa.com, @agilemanager
Making Promises with Kanban(and some often poorly understood fundamentals)
dja@djaa.com, @agilemanager
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
dja@djaa.com, @agilemanager
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
Done VerificationAcceptance3 3
dja@djaa.com, @agilemanager
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
Done VerificationAcceptance3 3
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
dja@djaa.com, @agilemanager
Delivery Rate
Lead Time
WIP=
Avg. Lead Time
Avg. Delivery Rate
WIP
Poolof
Ideas
ReadyTo
Deploy
Little’s Law
dja@djaa.com, @agilemanager
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
Done VerificationAcceptance3 3
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
dja@djaa.com, @agilemanager
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
dja@djaa.com, @agilemanager
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
Done VerificationAcceptance3 3
Reject
dja@djaa.com, @agilemanager
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
Done VerificationAcceptance3 3
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
dja@djaa.com, @agilemanager
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
dja@djaa.com, @agilemanager
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
dja@djaa.com, @agilemanager
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
Done VerificationAcceptance3 3
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
dja@djaa.com, @agilemanager
Psychology ofProbabilistic versus Deterministic
Approaches
dja@djaa.com, @agilemanager
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!
dja@djaa.com, @agilemanager
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
Done VerificationAcceptance3 3
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
dja@djaa.com, @agilemanager
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!
dja@djaa.com, @agilemanager
…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!
dja@djaa.com, @agilemanager
The Big Organizational Governance Question
dja@djaa.com, @agilemanager
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
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?
dja@djaa.com, @agilemanager
Liquidity in the housing market
Sellers BuyersBank
$100
$100
Cash
dja@djaa.com, @agilemanager
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
dja@djaa.com, @agilemanager
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
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!
dja@djaa.com, @agilemanager
Thinking of Kanban Systemsas a Market
dja@djaa.com, @agilemanager
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
So, how would we measure liquidity?
dja@djaa.com, @agilemanager
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
Pull Transactions in Kanban
Done
Poolof
Ideas
F
H
E
C A
I
Engin-eeringReady
Deploy-mentReady
GD
2 ∞
No Pull
Ongoing
Development Testing
Done VerificationAcceptance3 3
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.
dja@djaa.com, @agilemanager
Variety & Specialization increase WIP
Done
Poolof
Ideas
F
H
E
C A
I
Engin-eeringReady
Deploy-mentReady
GD
4 ∞
No Pull
Ongoing
Development Testing
Done VerificationAcceptance5 4
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!
dja@djaa.com, @agilemanager
Defining Liquidity for Kanban Systems
dja@djaa.com, @agilemanager
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
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
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
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....
dja@djaa.com, @agilemanager
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
dja@djaa.com, @agilemanager
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
dja@djaa.com, @agilemanager
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!
dja@djaa.com, @agilemanager
What Next?...
dja@djaa.com, @agilemanager
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?
dja@djaa.com, @agilemanager
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!
dja@djaa.com, @agilemanager
Conclusions
dja@djaa.com, @agilemanager
Building Liquidity Builds Trust in the System Highly liquid
systems should exhibit narrower
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.
dja@djaa.com, @agilemanager
Liquid Kanban Systems are Lean and Agile Kanban Systems Highly liquid
systems should exhibit narrower
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!
dja@djaa.com, @agilemanager
Thank you!
dja@djaa.com, @agilemanager
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
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
David J Anderson& Associates, Inc.
dja@djaa.com, @agilemanager
Appendix
dja@djaa.com, @agilemanager
Liquidity in the housing market
Sellers BuyersBank
$100
dja@djaa.com, @agilemanager
Liquidity in the housing market
Sellers BuyersBank
$100
$100
Cash
dja@djaa.com, @agilemanager
Example Distributions
Sta
ndardE
xpedit
e
Inta
ngib
le
Fixe
d D
ate
dja@djaa.com, @agilemanager
Recommended