Managing a Risky Business
Understanding Liquidity in
Flow

A proposed approach to
comparative assessment of
(software) ser...
Making Promises with Kanban
(and some often poorly understood fundamentals)

dja@djaa.com, @agilemanager
Commitment in Kanban
Pool
of
Ideas

Engineering
Ready

Ongoing

2

Testing

Development

3

Done

3

Verification Acceptan...
2nd Phase Delivery Commitment
Pool
of
Ideas

Engineering
Ready

2

Testing

Development
Ongoing

3

Done

F

3

Verificati...
Defining Lead & Cycle Time
Pool
of
Ideas

Engineering
Ready

2

Pull

Deploy-

The clock starts ticking when
ment
Testing
...
Little’s Law

=

Delivery Rate

Pool
of
Ideas

WIP
Lead Time

Avg. Lead Time
WIP

dja@djaa.com, @agilemanager

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

the systems. Th...
Identifying Buffers
Pool
of
Ideas

Engineering
Ready

Ongoing

2

F

GY

3

Done

verification Acceptance

I am a buffer!
...
Some Options Get Discarded
Pool
of
Ideas

Engineering
Ready

Ongoing

2

Testing

Development

3

3

Done

Verification Ac...
Flow the
Efficiency
Flow efficiency measures

Pool
Enginpercentage of total lead time
of spent actually adding value
eerin...
Observe Lead Time Distribution as an enabler
of a Probabilistic Approach to Management
Lead Time Distribution
3.5
3

CRs &...
Mean
5 days

Change Requests

Production Defects

Filter Lead Time data by Type of Work (and
Class of Service) to get Sing...
Allocate Capacity to Types of Work
Pool
of
Ideas

Engineering
Ready

Ongoing

2
Change
Requests

Development

4

3

Done

...
Psychology of
Probabilistic versus Deterministic
Approaches

dja@djaa.com, @agilemanager
Change Requests

The psychology of a probabilistic approach
can be challenging…

I don’t want to take the risk of
being lo...
Classes of Service Help Improve Trust
Engineering
Ready

2

Development
Ongoing

3

Testing

3

Done

Verification Accepta...
A lack of organizational social capital…
A lack of organizational social capital may
prevent trust in the kanban system fr...
…replace trust with comfort & reassurance

Deterministic planning provides a level of
comfort. Deterministic plans seem ac...
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...
Investment Bankers have an Answer…
But can we view kanban systems as

Investment bankers know how to answer this
markets o...
Liquidity in the housing market
Sellers

$100

Bank

Buyers

Cash
$100

dja@djaa.com, @agilemanager
Measuring Liquidity
The more transactions, the more
liquid the market
what is required are well matched buyers,
sellers an...
Adverse Market Conditions
In a market with lots of buyers but few well
matched sellers, inventory will be scarce, few
tran...
More Adverse Market Conditions
In a market with lots of sellers but few well
Hence, market grow and few
matched buyers inv...
Thinking of Kanban Systems
as 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 mark...
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 transa...
Pull Transactions in Kanban
Pool
of
Ideas

Engineering
Ready

2

F

Development
Ongoing

3

Done

Testing

3

Verification...
Variety & Specialization increase WIP
Pool
of
Ideas
∞

K

L

As a
DeployEngin- result, there will be a minimum level of
WI...
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...
Normalizing Liquidity Measures
To normalize this figure across
multiple systems, we could divide it
by the number of worke...
Pull Transactions / Person

Greater values for pull transaction
volume serve to show us the most
trustworthy system.
They ...
Characteristics of Liquid Markets
A liquid financial market would exhibit
several characteristics…
Tightness – bid-ask spr...
Characteristics of a Liquid Kanban
Market
A liquid kanban system would exhibit these
characteristics…
Tightness* – varianc...
Liquidity of the system should be
considered against observed capability
before placing an order
Some kanban systems may a...
Liquidity is a Good Metric
Our measure of liquidity, as pull
transaction volume per person or unit
of currency in a time p...
What Next?...

dja@djaa.com, @agilemanager
Field study to test its effectiveness is
now needed
Highly liquid
What is required now is to correlate
liquidity measures ...
Relevance of Liquidity as a Measure
Little’s Law

So our plans carry less
buffer for variation
Narrow spread of variation ...
Conclusions

dja@djaa.com, @agilemanager
Building Liquidity Builds Trust in the
System
Highly liquid
Measuring and reporting system
liquidity is important to build...
Liquid Kanban Systems are Lean and
Agile Kanban Systems Highly liquid
System liquidity provides an
important indicator, so...
Thank you!
dja@djaa.com, @agilemanager
About

David Anderson is a thought
leader in managing effective
software teams. He leads a
consulting, training and
publis...
Acknowledgements

Raymond Keating of CME Group in New Jersey has been instrumental
as a collaborator on the ideas in this ...
David J Anderson
& Associates, Inc.

dja@djaa.com, @agilemanager
Appendix

dja@djaa.com, @agilemanager
Liquidity in the housing market
Sellers

dja@djaa.com, @agilemanager

$100

Bank

Buyers
Liquidity in the housing market
Sellers

$100

Bank

Buyers

Cash
$100

dja@djaa.com, @agilemanager
Fixed Date

Intangible

Standard

Expedite

Example Distributions

dja@djaa.com, @agilemanager
dja@djaa.com, @agilemanager
Upcoming SlideShare
Loading in …5
×

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

819 views

Published on

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]

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
819
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
21
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 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. 2. Making Promises with Kanban (and some often poorly understood fundamentals) dja@djaa.com, @agilemanager
  3. 3. 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 dja@djaa.com, @agilemanager Done
  4. 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. 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
  6. 6. Little’s Law = Delivery Rate Pool of Ideas WIP Lead Time Avg. Lead Time WIP dja@djaa.com, @agilemanager Ready To Deploy Avg. Delivery Rate
  7. 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. 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. 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. 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. 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. 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. 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
  14. 14. Psychology of Probabilistic versus Deterministic Approaches dja@djaa.com, @agilemanager
  15. 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. 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. 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. 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
  19. 19. The Big Organizational Governance Question dja@djaa.com, @agilemanager
  20. 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. 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. 22. Liquidity in the housing market Sellers $100 Bank Buyers Cash $100 dja@djaa.com, @agilemanager
  23. 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. 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. 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
  26. 26. Thinking of Kanban Systems as a Market dja@djaa.com, @agilemanager
  27. 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. 28. So, how would we measure liquidity? dja@djaa.com, @agilemanager
  29. 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. 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. 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
  32. 32. Defining Liquidity for Kanban Systems dja@djaa.com, @agilemanager
  33. 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. 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. 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. 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. 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. 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. 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
  40. 40. What Next?... dja@djaa.com, @agilemanager
  41. 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. 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
  43. 43. Conclusions dja@djaa.com, @agilemanager
  44. 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. 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
  46. 46. Thank you! dja@djaa.com, @agilemanager
  47. 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. 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
  49. 49. David J Anderson & Associates, Inc. dja@djaa.com, @agilemanager
  50. 50. Appendix dja@djaa.com, @agilemanager
  51. 51. Liquidity in the housing market Sellers dja@djaa.com, @agilemanager $100 Bank Buyers
  52. 52. Liquidity in the housing market Sellers $100 Bank Buyers Cash $100 dja@djaa.com, @agilemanager
  53. 53. Fixed Date Intangible Standard Expedite Example Distributions dja@djaa.com, @agilemanager
  54. 54. dja@djaa.com, @agilemanager

×