Your SlideShare is downloading. ×
Key note - Lean Kanban Central Europe 2012 - Managing a Risky Business - Understanding Liquidity in Flow
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

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


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 …

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

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


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