Key Note - Software Executive Summit - Better predictability with kanban

  • 280 views
Uploaded on

Delivery better predictability, business agility and governance with Kanban. These three goals are often important to senior executives in technology companies. It is often assumed that these goals …

Delivery better predictability, business agility and governance with Kanban. These three goals are often important to senior executives in technology companies. It is often assumed that these goals are mutually exclusive and you have to focus on one, maybe two but all three cannot be achieved together. This talk presents Kanban for an executive audience and explains how it enables all 3 goals - better predictability, business agility without sacrificing governance.

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
280
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
12
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Delivering Better Predictability, Business Agility & Governance with Kanban Executives demand improved agility without sacrificing predictability & governance Software Executive Summit, Seattle, November 2012 dja@djaa.com, @agilemanager
  • 2. Background dja@djaa.com, @agilemanager
  • 3. Microsoft 2004 - the XIT Story Change requests PTCs Product Managers PM Testers RequestsDevelopers for estimates or analysis of future work are often ‚invisible‛, have an unpredictable arrival rate & are given priority. & Emergency work is unplanned User Acceptance receives highest priority. Arrival rate & volume are unpredictable. PTCs? What did that acronym mean? Items that did not require coding! Effect is hugely disruptive! Why were they treated as emergencies? Prioritized Backlog dja@djaa.com, @agilemanager Waiting for Test
  • 4. Predictability, Agility & Governance So how were they doing on our PTCs measures of predictability, agility & governance? Product Testers Developers Managers On-time delivery was 0%. There was a 100% chance of interruption to estimate future work. User Acceptance Planning & prioritization were conducted monthly. Fastest response from receipt to deployment was around 6 weeks. But everything had a business case and was prioritized by ROI! So the drive for good governance was Prioritized destroying predictability and agility! Waiting for Backlog Test dja@djaa.com, @agilemanager
  • 5. What Were the Issues? So what issues affected the outcome? PTCs were governance policies so Why disruptive? Testers Developers Product Managers Product managers demanded fast response on estimates to facilitate future planning and provide fast feedback to business owners. User Acceptance Entire backlog was planned & commitments made early. 90% of the backlog was re-planned each month. Expedite policy for PTCs was folklore – no one could explain why Process Improvement Conclusion Controlling unplanned, disruptive Prioritized demand would improve Waiting for Backlog predictability! Test dja@djaa.com, @agilemanager
  • 6. A virtual kanban system was chosen Backlog Engineering Ready 5 Change Requests Pull F F F F F F F PTCs G Development Test Ready Testing UAT 3 5 3 ∞ Ongoing Done It’s important to realize the process for software development did not B Pull change. The kanban system is an overlay on the existing process. It G C Pull changes scheduling and prioritization only F D PTCs are permitted to break the kanban limit *Blocked to service PTC dja@djaa.com, @agilemanager * I Deployment Ready ∞
  • 7. CRs 50 240% improvement in delivery rate The Results Backlog depleted. Serving at rate of demand 30 Average Time to Resolve 10 Time (in quarters) 125 90% drop in end-toend cycle time* 75 25 * Includes queuing time prior to selection dja@djaa.com, @agilemanager Time (in quarters)
  • 8. Understanding Kanban Systems dja@djaa.com, @agilemanager
  • 9. Kanban are virtual! Backlog Engineering Ready 5 Development Test Ready Testing UAT 3 5 3 ∞ Ongoing Done Change Requests Deployment Ready ∞ B Pull These are the virtual kanban F J G C F Pull Boards are not required to do F F Kanban! F I F The board D a visualization of the is F * The first system used database workflow process, the work-intriggers to signal pull. There was no progress and the (virtual) kanban PTCs board! Pull I dja@djaa.com, @agilemanager
  • 10. Commitment is deferred Backlog 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 E Wish to avoid discard after commitment PTCs Commitment point dja@djaa.com, @agilemanager We are committing to getting started. We are certain we want to take delivery. I Deployment Ready ∞
  • 11. Discard rates are often high Backlog 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 dja@djaa.com, @agilemanager Deployment Ready ∞
  • 12. Specific delivery commitment may be deferred even later DeployEnginBacklog 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 dja@djaa.com, @agilemanager 2nd Commitment point*
  • 13. Replenishment Cadence Backlog 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 dja@djaa.com, @agilemanager 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 ∞
  • 14. Delivery Cadence Backlog Engineering Ready Pull F F F F F F F Testing UAT 3 5 3 ∞ Ongoing Done Frequent deployment is more agile. 5 Change Requests Development Test Ready Deployment buffer size can On-demand deployment reduce as frequency of D deliveryagile! most increases G PTCs Discarded I dja@djaa.com, @agilemanager 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
  • 15. Defining Lead Time Backlog Engineering Ready 5 The clock starts ticking when Test UAT we Ready customers Development accept theTesting 5 ∞ 3 order, not when it3is placed! Ongoing Done Until then customer orders are merely available options Lead time (through Change Requests the kanban system) ends when the item reaches the first Pull F F F F F F F Deployment Ready ∞ D ∞ queue. I G E This provides the correct result for Little’s Law and visualization on a Cumulative Flow Diagram Lead Time PTCs Discarded I dja@djaa.com, @agilemanager
  • 16. Little’s Law WIP = Delivery Rate Lead Time Backlog Mean Lead Time WIP dja@djaa.com, @agilemanager Ready To Deploy Mean Delivery Rate
  • 17. Improving Agility dja@djaa.com, @agilemanager
  • 18. Factors Affecting Agility Kanban decouples replenishment from lead time & delivery enabling The businesstailoring of the process to the agility of the system is determined by the replenishment of the business domain dynamics cadence, the delivery cadence and the lead time (or end-to-end cycle time) through the system. dja@djaa.com, @agilemanager
  • 19. Benefits of Limiting WIP Backlog Engineering Ready 5 Change Requests Pull F F F F F F F G Development Test Ready Testing UAT 3 5 3 ∞ Ongoing Done Limiting WIP reduces multi-tasking. Shortens lead time. Focuses E organization on impediment removal D #* Bug and limits due date performance degradation from poor quality & rework Lead Blocked! Time PTCs *Specialist test environment unavailable Blocked! Discarded I I Defect found requiring coding fix dja@djaa.com, @agilemanager Deployment Ready ∞
  • 20. 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
  • 21. 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
  • 22. Allocate Capacity to Types of Work Backlog Engineering Ready Ongoing 2 Change Requests Development 5 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
  • 23. Flow Efficiency Flow efficiency measures the percentage of total lead time Pool is Engin- actually adding that spent of eering value (or knowledge) versus Development Ideas Ready waiting 3 Ongoing 2 Done Testing 3 Verification Acceptance Deployment Ready ∞ Until then customer orders are merely available options efficiency = Work Time Flow Lead Time Flow efficiencies of 2% have been F reported*. 5% -> 15% D normal, P1 is > 40% is good! G E PB I GY DE Waiting Working MN AB Waiting Working Waiting Lead Time * Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012 dja@djaa.com, @agilemanager Done x 100%
  • 24. Benefits of Reducing Lead Time Backlog Engineering Ready 5 Change Requests Pull F F F F F F F PTCs Discarded Development Test Ready Testing UAT 3 5 3 ∞ Ongoing Done Short lead times enable later commitment, reduce likelihood of post-commitmentE discard or rework D Bug due to perishable nature of Bug information and improve quality as G Bug defect insertion rates fall nonlinearly reduces chance of Short lead timewith reduced lead time discard Defect insertion rate increases non-linearly with long lead times and low flow efficiency. I Defect fix times increase nonlinearly with delay time from I discovery to fix dja@djaa.com, @agilemanager Deployment Ready ∞
  • 25. Flow Efficiency (%) More Results (from 2005) Flow efficiency improved from 8% to 92% 75 45 Due Date Performance 15 These improvements were minimally intrusive, met with little to no resistance (though some managerial derision) and cost almost nothing! 75 If Time (in quarters) well, it works this perhaps we should try this DPP improved again?!! almost instantly 45 15 * Measured from point of commitment dja@djaa.com, @agilemanager from 0% to 98% against lead time SLA* Time (in quarters)
  • 26. Ability to handle variety and heterogeneity of risks improves business performance Kanban enables us to build a trusted The kanban system explicitly exposes the delivery capability. Agility and business risks in terms of types of demand, predictability are tuned to the quantity & rate of demand. It helps us to understandinherent risks in the business the costs & benefits of frequent interaction with upstream & downstream domain! functions. And it gives us a temporary and quantitative understanding of our capability to deliver against demand dja@djaa.com, @agilemanager
  • 27. Better Governance dja@djaa.com, @agilemanager
  • 28. Key Risk to Manage is “What to Pull Next?” Pool of Ideas Engineering Ready 4 ∞ Development Ongoing 3 Done Deployment Ready Testing 3 Verification Acceptance ∞ Replenishing the system is an act of commitment – selecting items for delivery. Committing to the cost to convert from options into real value. J K L G Pull Selection is choosing from immediate options – an act of dynamic prioritization of the I have 4 options, which one Pull D most immediate risk attached to it E item with the should I choose? I System Replenishment F Pull Pull Selection dja@djaa.com, @agilemanager Done
  • 29. 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
  • 30. impact impact Cost of Delay is a critical business risk impact impact time Expedite – critical and immediate cost of delay; can exceed other kanban limit Qualitative approaches to risk (bumps other work) management using taxonomies of 2 to 6 time categories for each dimension of risk goes up Fixed date – cost of delay have been shown to fast, cheap & effective in significantly after deadline; Start early comparison to quantitative methods that to insure enough & dynamically prioritize often involve speculation and false on-time delivery time precision Standard - cost of delay is shallow but accelerates before leveling out; provide a reasonable lead-time expectation impact impact time time Intangible – cost of delay may be significant but is not incurred until much later; important but not urgent impact time time dja@djaa.com, @agilemanager
  • 31. Implementing Classes of Service Engineering Ready Development Ongoing Expedite Fixed Date Standard 3 Done 2 E D 3 F 1 I dja@djaa.com, @agilemanager 3 Verification Acceptance Different distributions for 2 different classes of service increases the level of trust that 1 an item will be delivered in a timely manner, demonstrating P1 that cost of delay is a risk under management G Intangible Testing Deployment Ready ∞ Done
  • 32. impact The Optimal Exercise Point 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 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 dja@djaa.com, @agilemanager
  • 33. Hedge Delivery Risk by spreading capacity across items of differing urgency Engineering Ready 2 Expedite Ongoing 2 3 Done Testing 3 Verification Acceptance ∞ 1 Fixed Date Development Deployment Ready Standard Uncertainty in demand or E arrival rate of urgent & critical items is offset with capacity for items that are easily delayed F D 3 G Intangible 3 I dja@djaa.com, @agilemanager Done
  • 34. Cost of Delay attaches to a deliverable 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 dja@djaa.com, @agilemanager
  • 35. Make a long term plan to build platform replacement Device Management Ike II Cumulative Flow 2008 30 -M ar 23 -M ar 5x 9M ar 2M ar eb 24 -F eb 2006 17 -F 10 -F Slope in middle 3.5x - 5x slope at ends 16 -M ar 240 220 200 180 160 140 120 100 80 60 40 20 0 eb Features Required throughput (velocity) During the middle 60% of the project schedule we Time need Throughput (velocity) to average 220 features Inventory Started Designed Coded Complete per month dja@djaa.com, @agilemanager
  • 36. Little’s Law Determines staffing level Calculated based on known lead time capability & required PlandeliveryChanging the WIP limit without based onrate currently observed maintaining the staffing level capability and current working ratio assume process practices. Do not represents a change to the way of working. It is a change to improvements. the process and will produce a Delivery Rateto reduce undesirable‘common change in the observed If changing WIP cause’ capability new effects (e.g. multitasking), get of the system Lead Time sample data (perform a spike) to observe the new capability From observed capability Target Treat as a fixed to variable achieve plan = dja@djaa.com, @agilemanager WIP
  • 37. Using Little’s Law Determines staffing level Calculated based on known lead time capability & required At this point perhaps just a little delivery rate black magic and experience may be required. If our current working WIP = 22 practices/process exhibited an Rounding 22 up to 25 would average WIP of 1 item per person then 55/week 25 people organized infor 5 teams we require conveniently provide 5 with to complete 5 items each teams of 5 peoplea WIP limit of the 0.4 weeks project on-time = From observed capability Target to achieve plan dja@djaa.com, @agilemanager Treat as a fixed variable
  • 38. 1 lane per team dja@djaa.com, @agilemanager
  • 39. WIP in this area should be 25 items* *photo taken early in the project before it was fully staffed/loaded Lead time Median lead time target is 2 days Alert managers if beyond 5 days dja@djaa.com, @agilemanager
  • 40. Conclusions dja@djaa.com, @agilemanager
  • 41. Kanban systems control variability that affect predictability Kanban systems defer commitments is Committing early improving quality of decision making comforting but can lead to and reducing unnecessary work and disappointment later. rework. Predictability is improved! Kanban builds trust enabling deferred commitment dja@djaa.com, @agilemanager
  • 42. Kanban enables improved agility Replenishment & delivery cadences are de-coupled and can be tuned to information arrival and overhead of the transaction. Industries such as media Lead time can be independent of require the decoupled replenishment & delivery cadence! dynamics of kanban to react to unfolding events dja@djaa.com, @agilemanager
  • 43. Kanban Improves Governance Visualization of the kanban system and explicit declaration of policies improves transparency on risk Kanban systems can management be designed to align directly There is no crystal ball gazing! Risk & gowith strategic plans analysis is not speculative! to-market strategies dja@djaa.com, @agilemanager
  • 44. Thank you! dja@djaa.com, @agilemanager
  • 45. 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 published in June 2012 is, Lessons in Agile Management – On the Road to Kanban. David is a founder of the Lean-Kanban University Inc., a business dedicated to assuring quality of training in Lean and Kanban for knowledge workers throughout the world. dja@djaa.com, @agilemanager
  • 46. Acknowledgements A virtual kanban system was first used with an offshore team within Microsoft’s IT department in 2004/2005. The Kanban Method as it is known today emerged at Corbis 2006/2007. Adoption of cumulative flow diagrams, Little’s Law, virtual kanban systems & cost of delay were heavily influenced by Donald Reinertsen. Major contributors to the material in this presentation include Daniel Vacanti, Jim Benson, Corey Ladas, Janice Linden-Reed, Troy Magennis, Chris Matts, Olav Maassen and Julian Everett dja@djaa.com, @agilemanager
  • 47. David J Anderson & Associates, Inc. dja@djaa.com, @agilemanager
  • 48. Appendix dja@djaa.com, @agilemanager
  • 49. 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 Intangible – delay causes embarrassment, loss of political capital, affects brand equity, mindshare, customer confidence, etc ? time dja@djaa.com, @agilemanager
  • 50. dja@djaa.com, @agilemanager Fixed Date Intangible Standard Expedite Example Distributions
  • 51. Visualize Risks to provide Scheduling Information Outside: Start Early Market Risk Items with the same shape carry the same risks and should be scheduled into the kanban system TS at approximately the same time. CR It is also wise to hedge risk by Do not Tech Risk Lifecycle New allocating prioritize items. From a whichever ones capacityprofile pick group for in the system of items Spoilrisk with the same items of differentMidprefer most Start Late risk profiles.Inside: you like or Unknown Soln Diff Cow Known but not us Done it before Commodity Intangible Disc Std Maj. Cap. ELE Delay Impact dja@djaa.com, @agilemanager FD Expedite Risk profile for a work item or deliverable Cost of Delay
  • 52. 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 dja@djaa.com, @agilemanager Junior who will be rotated through all 4 teams
  • 53. Market Risk of Change Profits Market Share etc Start Late Differentiators Spoilers Regulatory Changes Cost Reducers Scheduling Potentia l Value Market Risk Highly likely to change Table Stakes Highly unlikely to change dja@djaa.com, @agilemanager Start Early
  • 54. Aligning with Strategic Position or Go-to-Market Strategy DeployEngineering Ready 2 Table Stakes 3 Cost Reducer s 2 Spoilers Ongoing 3 Done Testing 3 Verification Acceptance ∞ Market segmentation can be used to narrow the necessary table stakes for any given market G niche! Enabling early delivery for narrower markets but potentially including value generating differentiating features E D 1 Differenti ators Development ment Ready 1 dja@djaa.com, @agilemanager F I Done
  • 55. Product Lifecycle Risk High Not well understood High demand for innovation & experimentation Low Profit Margin Major Growth Market Investment Product Risk Innovative/New Cash Cow Low Well understood Low demand for innovation dja@djaa.com, @agilemanager Low High
  • 56. Hedging Risk in a Portfolio Kanban Horizational position shows percentage complete Allocation of personnel Complete Total = 100% 0% Cash Cows 10% budget Innovative/New 30% budget B A Growth Markets 60% budget D C K E G F dja@djaa.com, @agilemanager Complete 100% Projects-in-progress Color may indicate cost of delay (or other risk) H
  • 57. 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 risk and so forth. a specific business. It may be necessary to run a workshop with stakeholders to explore and expose the real business risks requiring management dja@djaa.com, @agilemanager
  • 58. dja@djaa.com, @agilemanager