Key Note - Lean Kanban North America 2013 - Beyond Kanban


Published on

Getting beyond the use of kanban systems and the Kanban Method to truly improve business performance through improved risk management. This talk looks at both the qualitative and quantitative risk management techniques enabled by the Kanban. And defines a measure of kanban system liquidity that can be used as a leading indicator to monitor the effectiveness and reliability of probabilistic forecasts based on historical system performance

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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.
  • I can clean up the shapes (background white color – a bit sloppy)… Thinking that we may need a slide before this transitioning into this slide ?
  • Key Note - Lean Kanban North America 2013 - Beyond Kanban

    1. 1. Beyond Kanban Managing Investment in Knowledge Work against Business Risks Kanban enabled qualitative and quantitative risk management David J. Anderson Raymond Keating Lean Kanban Conference Chicago, 1st May 2013, @djaa_dja
    2. 2. Part 1 - Introduction, @djaa_dja
    3. 3. Some Core Kanban Concepts, @djaa_dja
    4. 4. Commitment is deferred Backlog Pool of Ideas Engineering Ready 5 Testing UAT 3 5 3 ∞ Ongoing Done Items in the backlog remain optional and unprioritized Change Requests Pull F F F F F F F Development Test Ready D G Wish to avoid discard after commitment PTCs Commitment point, @djaa_dja E We are committing to getting started. We are certain we want to take delivery. I Deployment Ready ∞
    5. 5. Discard rates are often high Pool of Ideas Engineering Ready 5 Development Test Ready Testing UAT 3 5 3 ∞ Ongoing Done The discard rate with XIT was 48%. ~50% is commonly observed. Change Requests F F F F G Reject Deferring commitment and Options have value because the avoiding interrupting future is Dworkersuncertain for estimates E 0%makes rate implies there is discard sense when discard no uncertainty about the future rates are high! PTCs I Discarded I, @djaa_dja Deployment Ready ∞
    6. 6. Upstream Kanban Prepares Options Pool of Ideas Biz Case Dev Requirements Analysis Ready for Engineering ∞ 24 - 48 12 - 24 4 - 12 K L Min & Max limits insure sufficient options are always available Committed 4 Development Testing 3 3 Ongoing Done Verification J I D F Options $$$ cost of acquiring options Reject Discarded O P Q Commitment point, @djaa_dja Committed Work
    7. 7. Replenishment Frequency Pool of Ideas Engineering Ready 5 Replenishment Change Requests Pull F F F F F F F Development Test Ready Testing UAT 3 5 3 ∞ Ongoing Done Frequent replenishment is more agile. On-demand replenishment is D most agile! G PTCs Discarded I, @djaa_dja E The frequency of system replenishment should reflect arrival rate of new information and the transaction & coordination I costs of holding a meeting Deployment Ready ∞
    8. 8. Delivery Frequency Pool of Ideas Change Requests Pull F F F F F F F Engineering Ready Development Test Ready Testing UAT 3 5 3 ∞ Ongoing Done Frequent deployment is more agile. 5 Deployment buffer size can On-demand deployment reduce as frequency of D deliveryagile! most increases G PTCs Discarded I, @djaa_dja is E The frequency of delivery should reflect the transaction & coordination costs of deployment plus costs & toleranceI of customer to take delivery Deployment Ready ∞ Delivery
    9. 9. Specific delivery commitment may be deferred even later DeployEnginPool of Ideas eering Ready 5 Development Test Ready Testing UAT 3 5 3 ∞ Ongoing Done ment Ready ∞ Change Requests Pull F F F F F F F D G E PTCs We are now committing to a specific deployment and delivery date Discarded *This may happen earlier if I circumstances demand it I, @djaa_dja 2nd Commitment point*
    10. 10. Defining Kanban System Lead Time Pool of Ideas Engineering Ready 5 Deployment Ready ∞ The clockTest starts ticking when UAT we customers Ready Development accept the Testing is 5 ∞ 3 order, not when it 3 placed! Ongoing Done Until then customer orders are merely available options Change Requests Pull F F F F F F F D G E System Lead Time PTCs I Discarded I, @djaa_dja Lead time ends when the item reaches the first ∞ queue.
    11. 11. Little’s Law & Cumulative Flow Delivery Rate Pool of Ideas = Lead Time Avg. Lead Time WIP, @djaa_dja WIP Ready To Deploy Avg. Delivery Rate
    12. 12. 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 Multitasking means time spent E in working columns is often waiting time PB GY DE Waiting Working MN AB Waiting Working Waiting Lead Time * Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012, @djaa_dja x 100% Lead Time Flow efficiencies of 2% have been F reported*. 5% -> 15% D normal, P1 is > 40% is good! G I Done
    13. 13. 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! Mean of 31 days The workexpectation of SLA is of two types: Change Requests (new 105 and Production features);days with 98 % Defects SLA expectation of 44 days with 85% on-time, @djaa_dja on-time
    14. 14. Mean 5 days Change Requests Production Defects Filter Lead Time data by Type of Work (and Class of Service) to get Single Mode Distributions 98% at 25 days 85% at 10 days, @djaa_dja 98% at 150 days Mean 50 days 85% at 60 days
    15. 15. 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, @djaa_dja Separate understanding of Separate understanding of Lead Lead Time for each type of Time for each type of work work Lead Time ∞ Done
    16. 16. Defining Customer Lead Time Pool of Ideas Engineering Ready Development Test Ready Testing UAT 3 5 3 ∞ Ongoing 5 Change Requests Done The clock still starts ticking when we accept the customers order, not when it is placed! Deployment Ready ∞ Pull F F F F F F F D G E Customer Lead Time PTCs Discarded I, @djaa_dja The frequency of delivery cadence will affect customer I lead time in addition to system capability Done ∞
    17. 17. impact The Optimal Time to Start If we start too early, we forgo the option and opportunity to do something else that may provide value. If we start too late we risk Ideal Start incurring the cost of delay time When we need it Here With a 6 in 7 chance of on-time delivery, we can always expedite to insure on-time delivery 85th percentile Commitment point, @djaa_dja
    18. 18. Part 2 Qualitative Risk Management, @djaa_dja
    19. 19. The Key to Governance of Portfolio Risk, @djaa_dja
    20. 20. Simplifying Alignment & Corporate Governance Kanban systems enable a Our business has defined promises to our greatly shareholders in terms of model forservices simplified the products, management and markets we operate within and our of risk & corporate governance tolerance to risk. If we can show that we develop good, innovative ideas within those bounds and that our people are always working on the best of those available choices, we can claim appropriate use of shareholders’ funds, @djaa_dja
    21. 21. Risk #1 Are we creating the right ideas? Pool of Ideas Biz Case Dev Requirements Analysis Ready for Engineering ∞ 24 - 48 12 - 24 4 - 12 W Q X ZS R Y T AA U K L Q R S FT J I U1 U Committed 4 Development Testing 3 3 Ongoing K L J F I D Ideas should reflect opportunities to exploit & be classified by the business risks they Commitment point address, @djaa_dja Done Verification
    22. 22. Risk #2 What to Pull Next? Pool of Ideas Biz Case Dev Requirements Analysis Ready for Engineering ∞ 24 - 48 12 - 24 4 - 12 Committed 4 Development Testing 3 3 Ongoing Done Verification Acceptance I have 4 options, which one should I Replenishing the system is an act of commitment K choose? J – selecting items for delivery – for conversion L from options into real value. Pull Pull Selection is choosing from immediate Pull I options – ideally dynamic selection of the item with the most immediate risk attached to it by a D suitably skilled F member of the team Replenishment Pull Selection Commitment point, @djaa_dja
    23. 23. Risk Assessment, @djaa_dja
    24. 24. A Lean approach to alignment with business risks uses Qualitative Assessment But how do we determine the risks in We need a work item that we must manage? a fast, cheap, accurate, consensus forming approach to risk assessment. We need Lean Risk Assessment! The answer is to use a set of qualitative methods to assess different dimensions of risk such as urgency, @djaa_dja
    25. 25. Sketch market payoff function Room nights sold per day Cost of delay for an online Easter holiday marketing promotion is difference in integral between the two curves Estimated additional rooms sold Cost of delay Actual rooms sold time When we need it, @djaa_dja When it arrived
    26. 26. impact Cost of Delay based on Market Payoff Sketches Treat as a Standard Class item Total cost of delay time Cost of delay function for an online Easter holiday marketing campaign delayed by 1 month from mid-January (based on diff of 2 integrals on previous slide), @djaa_dja
    27. 27. impact impact Establish urgency by qualitative matching of cost of delay sketches time impact impact time time time Intangible – cost of delay may be significant but is not incurred until much later; important but not urgent impact time Fixed date – cost of delay goes up significantly after deadline; Start early enough & dynamically prioritize to insure on-time delivery Standard - cost of delay is shallow but accelerates before leveling out; provide a reasonable lead-time expectation impact impact time Expedite – critical and immediate cost of delay; can exceed kanban limits (bumps other work) time, @djaa_dja
    28. 28. impact Cost of Delay has a 2nd Dimension Working capital impact time Working capital impact time Extinction Level Event – a short delay will completely deplete the working capital of the business Major Capital – the cost of delay is such that a major initiative or project will be lost from next year’s portfolio or additional capital will need to be raised to fund it Discretionary Spending – departmental budgets may be cut as a result or our business misses its profit forecasts impact time ? time, @djaa_dja Intangible – delay causes embarrassment, loss of political capital, affects brand equity, mindshare, customer confidence, etc
    29. 29. 3rd Dimension: Shelf-Life Risk Short (days, weeks, months) Known Expiry Date, Seasonal (fixed window of opportunity) Medium (months, quarters, 1-2 years) Long (years, decades), @djaa_dja Fashion Craze Fad
    30. 30. Shelf-Life Risk Many High High Schedule Risk (days, weeks, months) Innovation Number of Options Short Known Expiry Date, Seasonal (fixed window of opportunity) Medium (months, quarters, 1-2 years) Long (years, decades) Few Low Low, @djaa_dja Fashion Craze Fad
    31. 31. Shelf-Life Risk Schedule Risk Low High High Many (months, quarters, 1-2 years) Number of Options (window of opportunity) Medium Fashion Craze Fad Innovation Known Expiry Date, Seasonal Differentiator (days, weeks, months) Spoiler/Follower Short Low Low Few Long (years, decades), @djaa_dja Low If we are market leading our innovations are less time critical
    32. 32. impact When should we start something? If we start too early, we forgo the option and opportunity to do something else that may provide value. If we start too late we risk Ideal Start incurring the cost of delay time When we need it Here With a 6 in 7 chance of on-time delivery, we can always expedite to insure on-time delivery 85th percentile Commitment point, @djaa_dja
    33. 33. Risk is a multi-dimensional problem So understanding cost of delay Yes, however, it isn’t always relevant! Cost of enables us to know what to pull delay attaches to a deliverable item. What if next? that item is large? Whole projects, minimum marketable features (MMFs) or minimum viable products (MVPs) consist of many smaller items. We need to understand the risks in those smaller items too, if we are to know how to schedule work, replenish our system and make pull decisions wisely, @djaa_dja
    34. 34. Market Risk of Change Profits Market Share etc Start Late Differentiators Spoilers Regulatory Changes Cost Reducers Scheduling Potentia l Value Highly likely to change Market Risk Build (as rapidly as possible) Table Stakes Buy (COTS) Rent (SaaS), @djaa_dja Highly unlikely to change Start Early
    35. 35. Product Lifecycle Risk High Not well understood High demand for innovation & experimentation Low Major Growth Market Investment Growth Potentia l Product Risk Innovative/New Cash Cow Low, @djaa_dja Well understood Low demand for innovation Low High
    36. 36. Risk is a multi-dimensional contextual problem These are just useful examples! We must develop a set of We can easily envisage other risk dimensions risk such as technical risk,that work in context for taxonomies vendor dependency risk, organizational maturity riskbusiness. a specific and so forth. It may be necessary to run a workshop with stakeholders to explore and expose the real business risks requiring management, @djaa_dja
    37. 37. Risk Management, @djaa_dja
    38. 38. Understanding our tolerance to different risks We need to decide what we value as a business, our strategic What are our expectations for position & our predictability, business agility, profitability? go-to-market strategies Are our current capabilities aligned with our expectations? Have we a clearly stated strategic position and set of go-to-market strategies?, @djaa_dja
    39. 39. Matching Cost of Delay Risk to Capability Business Agility If we have many fixed date requirements we need a reasonably strong business agility capability and a lot of predictability Standard Delivery Predictability Replenishment High for predictability will work. However, our business will be constantly in a reactive mode Fixed Date Lead Time Where does our Frequent Short Frequent Predictability business currently Not Applicable Expedite If we suffer a lot of expedite demand, strong rank on with business agility without a need these sliders? capability Intangible Low, @djaa_dja Seldom Long Seldom
    40. 40. Matching Shelf-Life Risk to Capability Business Agility Where does our High business currently Short (days, weeks, rank on these sliders? Frequent Short Frequent Lead Time Replenishment Predictability Are our business strategy and expectations aligned with our currently observed capabilities? If we plan to Medium pursue short shelf-life opportunities, do we have the agility and (months, predictability to pull it off? quarters, 1-2 years) Delivery months) Long Low (years, decades) Seldom Long Kanban system dynamics, @djaa_dja Seldom
    41. 41. Matching Market Risk of Change to Capability Business Agility Where does our Less Highly regulated industries requireFrequent Short Frequent predictability in delivery business currently capability Differentiators Lead Time Predictability Replenishment To pursue a strategy of innovation or fast market following we need a high level of business agility – fast, frequent Spoilers delivery Regulatory To be innovative or Changes fast following in a highly More regulated industry requires us to be both predictable and exhibit a high level of business Cost Reducers agility Delivery rank on these sliders? Table Stakes Less, @djaa_dja Seldom Long Seldom
    42. 42. Understanding capability is critical to our risk management strategy If you cannot assess your current delivery capability and align your strategy and marketing plans accordingly, then … You are doomed before you start!, @djaa_dja
    43. 43. How much risk do you want to take? Given our current capabilities, our desired strategic position and goWe only have capacity to do so much work. How we allocate that capacity across different risk to-market strategies, how much risk dimensions will determine how aggressive we do you want to take? are being from a risk management perspective. The more aggressive we are in allocating capacity to riskier work items the less likely it is that the outcome will match our expectations, @djaa_dja
    44. 44. Hedge Delivery Risk by allocating capacity in the kanban system DeployEngineering Ready 2 Expedite Development Ongoing 3 Testing 3 Done Verification Acceptance 1 P1 AB Fixed Date 2 E D MN PB Standard 3 F G GY Intangible 3 I, @djaa_dja DE ment Ready ∞ Done
    45. 45. Aligning with Strategic Position or Go-to-Market Strategy DeployEngineering Ready Cost Reducer s 3 2 3 Testing 3 Ongoing Done Verification Acceptance niche! Enabling early delivery for narrower P1 markets but potentially including value AB DA generating differentiating features E D MN PB Spoilers 1 F GY Differenti ators Done The concept of a minimum viable ∞ product (MVP) will contain the table Market segmentation can be used to narrow the stakes for at least given market necessary table stakes for any 1 market niche G 2 Table Stakes Development ment Ready 1, @djaa_dja I DE
    46. 46. Trade off growing market reach against growing share & profit within Deploya niche EnginCapacity allocated to Table Stakes will ment eering determine how fast new niches can be Ready Development Testing Ready Cost Reducer s 3 developed. 3 It is important to define a MVP in ∞ Allocate more to Table Stakes to speed market terms of table stakes and reach/breadth. differentiators required to enter a G specific market segment Allocate more to differentiators to grow P1 2 Table Stakes 3 Ongoing Done Verification Acceptance market share or AB profit margins DA 2 E Allocate D more to spoilers to defend market share MN PB Spoilers 1 F GY Differenti ators Done 1, @djaa_dja I DE
    47. 47. Visualizing Risks on a Kanban Board, @djaa_dja
    48. 48. Visualize Risks on the Ticket Decorators Title Typically used to indicated technical or skillset risks H Checkboxes… risk 1 risk 2 risk 3 risk 4 SLA or Target Date, @djaa_dja Letter req complete Color of the ticket Business risk visualizatio n highlighted in green
    49. 49. Visualize Risks on the Board Engineering Ready 2 Expedite Development Ongoing 3 Testing 3 Done Verification Acceptance 1 P1 AB Fixed Date 2 E D MN PB Standard 3 F G GY Intangible 3 I, @djaa_dja DE Deployment Ready ∞ Done
    50. 50. Abandon Prioritization. Banish Priority Prioritization is waste! Prioritization is an exercise to schedule variable for real business Priority is a proxya sequence of items at a risk information. specific point in time. Only at the Do not point ofbehind a proxy. Enable better mask risk commitment can a proper assessment be made making by governance and better decision of what to exposing the business risks under management on pull next. Filter options based throughout the workflow kanban signals. Select from filtered subset, @djaa_dja
    51. 51. Part 3 Quantitative Risk Management, @djaa_dja
    52. 52. 2 Real Business Problems Probabilistic Forecasting requires me to trust that future system capability will reflect If given a choice of systems in which to placethe business, I would like torecent past choice (relatively) know the best capability Lowest price Fastest delivery Most predictable delivery, @djaa_dja
    53. 53. Comparative Assessment We need a method to monitor the “trustworthiness” of the system that makes comparative assessment of currently observed capability against We need a comparative assessment historical observations within the same system method to assess comparative capability across different systems Must be a leading indicator, @djaa_dja
    54. 54. Comparative Assessment, @djaa_dja
    55. 55. Analysis of Cost Distribution System A Cost($) Per Item Frequency 10 8 6 4 Frequency 2 0 200 400 600 800 1000 1200 1400 1600 1800 2000 2400 2800 3200 3600 4600 6400 6600 More Cost Per Item in $ Average cost / item = $2218 Frequency System B Cost($) Per Item 14 12 10 8 6 4 2 0 Frequency 200 400 600 800 1000 1200 1400 1600 1800 2000 2200 2400 2600 2800 3000 3600 4000 4200 5400 More Cost Per Item in $ Can you tell which system is better?, @djaa_dja Average cost / item = $1723
    56. 56. Analysis of Throughput Distribution System A Throughput 25 System B Throughput Mean 1.00 / day 20 15 20 Mean 1.15 / day 15 10 10 5 5 0 0 0 1 2 3 4 More 0 Number of Tickets Per Day Can you tell which system is better?, @djaa_dja 2 3 Number of Tickets Per Day System B Throughput System A Throughput 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 1 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0 4 More
    57. 57. Lead Time Distributions System B System A Mean 17 days Mean 12 days 30 14 12 10 8 6 4 2 0 25 20 15 Frequency 10 Frequency 5 0 5 10 15 Lead Time (Days) 20 10 8 6 4 Frequency 45 40 35 30 25 20 15 10 5 0 Frequency -15 Lead Time Expectation Spread (Days) More System B 12 0 30 Lead Time in Days System A 2 25 -10 -5 0 5 10 15 20 More Lead Time Expectation Spread (Days) System B is clearly faster with better due date performance (but are they processing work of similar complexity & size?), @djaa_dja
    58. 58. Comparison System A System B Cost (avg per item) $2218 $1723 Throughput (avg per day) 1.00 1.15 Lead time (mean days) 17 12 Avg system WIP (items) 17 14 Avg. WIP per State 4.25 2.8 Due Date Performance (% within expectation) 42% 75% • • • • • System A costs 29% more per item than System B System B has 15% higher delivery rate than System A System B is typically 5 days (or 29%) faster than System A System B delivers 33% more items within expectation Total WIP is not significantly different in either system, @djaa_dja
    59. 59. Comparative assessment • System B has a lower average cost and a more “normal” distribution of cost • System B has marginally faster delivery rate and smoother flow of delivery • System B has shorter lead times with more superior due date performance • Systems A & B have similar amounts of WIP • System B does appear a better choice but doubts remain over whether it would perform as well, if given the same work as System A., @djaa_dja
    60. 60. Liquidity, @djaa_dja
    61. 61. Where is the best place to place a work order to best manage risk? But can we view kanban systems as Investment bankers know how to answer this markets for software question! They prefer to place orders in liquid 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., @djaa_dja
    62. 62. Liquidity in the housing market Sellers $100 Bank Buyers Cash $100, @djaa_dja
    63. 63. 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, bridging loans or cash measured Market liquidity is buyers injecting capital into the system, to fund the transaction volume transactions . when these conditions are present transactions will take place!, @djaa_dja as
    64. 64. 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, @djaa_dja
    65. 65. 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, @djaa_dja
    66. 66. So, how would we measure liquidity?, @djaa_dja
    67. 67. Measuring Liquidity, @djaa_dja
    68. 68. Measuring Real Liquidity… If we recall, liquidity is measured as transaction volume in the market. So what are the transactions in a kanban system?, @djaa_dja
    69. 69. 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, @djaa_dja Done
    70. 70. 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, @djaa_dja Done
    71. 71. Can you tell which of these systems is more liquid?, @djaa_dja
    72. 72. Liquidity is measured as derivative of the rate of pull transactions To make the measure robust to the number of states in the kanban system, the amount of WIP and the number of workers involved, we propose the derivative of the rate of pull transactions as the indicator of liquidity., @djaa_dja
    73. 73. Analysis of Derivative of Pulls The derivative shows us clearly that System B has smoother flow and is a more liquid system, @djaa_dja
    74. 74. Comparative assessment Assessing the spread of variation in the derivative of pull transactions gives us a metric for assessing the predictability of a kanban system. A narrow spread in the derivative shows a smooth flowing (laminar) system that is likely highly predictable. A wider spread implies turbulent or unpredictable flow implying higher risk, @djaa_dja
    75. 75. Trustworthiness A trustworthy kanban system will exhibit smooth laminar flow. The spread in the derivative values will be narrow. Such systems are most likely to offer the most predictable results., @djaa_dja
    76. 76. Managing Risk with Liquidity Metrics Probabilistic forecasting in Kanban is based on the assumption that the recent past will reflect the near future. We must monitor the derivative of the rate of pull transactions. Changes in the rate of pull may indicate that the recent past, no longer reflects our current reality. Hence, probabilistic forecasts are at risk, @djaa_dja
    77. 77. 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...., @djaa_dja
    78. 78. Assessing Liquidity Kanban System A liquid kanban system would exhibit these characteristics… Tightness – spread in derivative of pull transactions indicating trustworthiness and likelihood of on-time delivery Immediacy – shape of lead time distribution (mode, median, mean, and tail 85%ile, 98%ile) Breadth – variety of types of work handled (incl size from single requests to large projects) 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…, @djaa_dja
    79. 79. Analysis of Derivative of Pulls Some of the derivative A histogram and run chart work remains to make it of pull transactions robust clearly the shows to recirculation of tickets And… on the board liquidity in the kanban system Experimentation is needed to This metric is independent of the sample of re-cycling determine how far When to number back encountering tickets(negative states in the workflowprovideamount ofpull) the the distribution to or the sufficient WIP resulting positive pull should data to indicate current normal not be counted operating range for liquidity, @djaa_dja
    80. 80. Visualizing Liquidity, @djaa_dja
    81. 81. Liquidity Board Deconstructed Immediacy – Lead Time SLA Color of shape represents age Tightness – Derivative of pull transactions Breadth – Types of worked pulled (Size) Depth – Managed Risk Resilience – Recover to normal circumstances after an exceptional period, @djaa_dja SLA Not Met Relatively old SLA Met Relatively young Green arrow pull transaction Large High Med Med Smal l Low SLA is affected briefly due to swings in Breadth, Depth and Immediacy, but comes back to normal.
    82. 82. System A – Liquidity Board • Immediacy – Lead time SLA is met less than 50% of the time and work items stay in a work state for a relatively long period of time • Tightness – Inconsistent number of pulls through the workflow • Breadth – Little variance in breadth size of items typically small or medium • Depth – Little variance in managed risk items are typically low in risk • Resilience – Once the system has one to two large items come in it really never recovers, @djaa_dja
    83. 83. System B – Liquidity Board • Immediacy – Lead time SLA is met 80 % of the time and work items stay in a work state for a relatively short period of time • Tightness – Relatively consistent number of pulls through the workflow • Breadth – large variance in breadth; size of items range from small to large • Depth – Large variance in managed risk, items range from low to high • Resilience – Once the system takes on large items and high risk the SLA suffers, but eventually recovers, @djaa_dja
    84. 84. Decisions to Route Work System A should only be given We should encouragethat is known to be small work managers in System A to adoptis not timeand and practices critical techniques can in So what conclusions usedwe System B draw about how to route work be trusted with a System B can We are likely to within this organization? place new (in size and risk greater variety investment in System B as we trust especially profile) of work and the managers bettercriticala more time to run work liquid system, @djaa_dja
    85. 85. Summarizing Liquidity, @djaa_dja
    86. 86. 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, @djaa_dja Observed Capability
    87. 87. Liquidity is a Good Metric Our measure of liquidity, as pull transaction volume and the spread of its derivative, meets the criteria* for a useful metric… Liquidity is a global system Simple measure. Self-generating Relevant Driving it up should not cause Leading Indicator local optimization or undesired consequences! * Reinertsen, Managing the Design Factory 1997, @djaa_dja Observed Capability
    88. 88. Relevance of Liquidity as a Measure Little’s Law So our plans carry less buffer for variation In order to have confidence that our Narrow spread of forecasts,in leadon probabilistic variation based And time (recent) historical data more for a fixed WIP means a for the predictable delivery rate. This is distribution of lead times, are turn means greater must monitor the can Our planning horizons accurate, we predictability on delivery date for a given volume as an derivative of pull transactions be shorter! of work and therefore a more indicator that the risk isn’t changing accurate price., @djaa_dja
    89. 89. Improving Liquidity through Labor Pool Flexibility Engineering Ready Teams 3 F Cost Reducer s Spoilers 2 1 3 Development Testing 3 Verification Acceptance Steven Brian Done Ongoing Done flexibly across rows on the board to keep work flowing G GY Differenti ators 1 3 It’s typical to see splits of Promotions from fixed team workers versusjunior team member to flexible flexible system workers Joe Dworker with David of between 40-60% an avatar P1 clearly visualize why a pay PB DE rise is justified. Flexible Peter Roughly half the labor E Rhonda workers help manage Generalist or T-shaped pool are flexible workers MN people who can move liquidity risk better! AB Ongoing 2 Table Stakes Team LeadAnalysis Joann Ashok, @djaa_dja Junior who will be rotated through all 4 teams
    90. 90. Conclusions, @djaa_dja
    91. 91. Kanban enables new powerful approaches to risk management in knowledge work Kanban systems enable us to visualize many dimensions of real business risks. Kanban is enabling the practical with capacity Hedging risks is possibleapplication of allocation in the system real option theory and related concepts like real liquidity, @djaa_dja
    92. 92. Qualitative Approaches are Lean Qualitative approaches to risk assessment are fast, cheap and drive Stop speculating about consensus business value and ROI. There is no crystal ball gazing! Riskrisks Instead assess real analysis is not speculative! and design kanban systems to manage them!, @djaa_dja
    93. 93. Quantitative Approaches are also Lean Quantitative approaches to using historical data and probabilistic Stop speculating about forecasting are viable and cheap and hence Lean! future outcomes. Forcast probabilistically and to assess trustworthiness of forecasts! There is no crystal ball gazing! Risk monitor the liquidity analysis is not speculative!, @djaa_dja
    94. 94. Don’t Set Yourself Up for Failure Know your your strategic plan If current capabilities! & marketing objectives are Lead time distributions & not aligned with your replenishment and delivery cadence define business agility! current capabilities, you many be doomed before you start!, @djaa_dja
    95. 95. Kanban & Qualitative Risk Assessment are powerful in combination Kanban systems address variability in, and focus attention on improving, Fullyflow! exploit Kanban-enabled business agility to delivery Improved predictability & business better business outcomes agility from Kanban is only valuable if through qualitative & exploited quantitative risk management, @djaa_dja
    96. 96. Thank you!, @djaa_dja
    97. 97. 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., @djaa_dja
    98. 98. About Raymond Keating has 20 years’ experience in the financial and technology industry developing and managing trading systems for major financial institutions such as J.P. Morgan, Republic National Bank, HSBC, NYMEX and the CME Group. Ray is an Accredited Kanban Trainer through the LKU. Currently Raymond is Director of Software Engineering at the CME Group. Functioning as the development manager for the ClearPort trading application and change agent for the group he has evolved the processes and policies by applying the core practices of Kanban. Recently Raymond has been researching applying the characteristics of market liquidity to a Kanban system., @djaa_dja
    99. 99. Acknowledgements Donald Reinertsen directly influenced the adoption of virtual kanban systems and the assessment of cost of delay & shelf-life as criteria for scheduling work into a kanban system. Chris Matts & Olav Maassen strongly influenced the concept of options & commitments and the upstream min-max limits is based on an example first presented by Patrick Steyaert. We’d like to thank Andrew Milne for the animation of liquidity visualization and CME Group for their collaboration and access to data to demonstrate the quantitative theories presented here, @djaa_dja
    100. 100. David J Anderson & Associates, Inc., @djaa_dja
    101. 101. Appendix, @djaa_dja
    102. 102., @djaa_dja Fixed Date Intangible Standard Expedite Example Distributions
    103. 103., @djaa_dja