Colors in Projects 2013 Bucharest - Kanban Briefly Explained

659 views
411 views

Published on

The use of virtual kanban systems in creative knowledge work and the wider Kanban Method for successful evolutionary change in your technology business - briefly explained! From the Colors in Projects conference in Bucharest, Romania, March 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
659
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
23
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Colors in Projects 2013 Bucharest - Kanban Briefly Explained

  1. 1. Kanban Successful Evolutionary Change for your Technology Business What is Kanban? How do you implement it? What are the benefits? Color in Projects Bucharest, March 2013 dja@djaa.com, @djaa_dja
  2. 2. A story to get us started dja@djaa.com, @djaa_dja
  3. 3. Microsoft 2004 - the XIT Story Change requests Product Managers PTCs Requests for estimates of future work are often ‚invisible‛, have an Testers Developers unpredictable arrival rate & are given priority. Discard rate of estimated future & Emergency work is unplanned User Acceptance work ishighest priority. Arrival rate receives often 50% or greater! & 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, @djaa_dja Waiting for Test
  4. 4. Capability & Customer Satisfaction What was the observed capability of PTCs this department? How was customer satisfaction? Product Testers Developers Managers delivery was 0%. There was a 100% On-time chance of interruption to estimate future work. User Acceptance Planning & prioritization were conducted monthly. Fastest response from receipt to deployment was around 6 weeks, average 5 months, slow 1 year plus. But everything had a business case and was prioritized by ROI! Budgets were well governed but Prioritized customer satisfaction was poor! Waiting for Backlog Test dja@djaa.com, @djaa_dja
  5. 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 So controlling the unplanned, disruptive demand would improve Prioritized Waiting for predictability! Backlog Test dja@djaa.com, @djaa_dja
  6. 6. What is a kanban system? dja@djaa.com, @djaa_dja
  7. 7. A Kanban Systems consists of “kanban” signal cards in circulation dja@djaa.com, @djaa_dja
  8. 8. Kanban as a solution for XIT dja@djaa.com, @djaa_dja
  9. 9. 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, @djaa_dja * I Deployment Ready ∞
  10. 10. 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 delivery time* 75 25 * Includes queuing time prior to selection dja@djaa.com, @djaa_dja Time (in quarters)
  11. 11. What is a kanban system? (& how to implement one for knowledge work) dja@djaa.com, @djaa_dja
  12. 12. 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 dja@djaa.com, @djaa_dja E We are committing to getting started. We are certain we want to take delivery. I Deployment Ready ∞
  13. 13. 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 dja@djaa.com, @djaa_dja Deployment Ready ∞
  14. 14. 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 dja@djaa.com, @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 ∞
  15. 15. 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 dja@djaa.com, @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
  16. 16. 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 dja@djaa.com, @djaa_dja 2nd Commitment point*
  17. 17. 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 dja@djaa.com, @djaa_dja Lead time ends when the item reaches the first ∞ queue.
  18. 18. 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 dja@djaa.com, @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
  19. 19. What is the Kanban Method? dja@djaa.com, @djaa_dja
  20. 20. Kanban Method A management & cultural approach to improvement View creative knowledge work as a set of services Encourages a management focus on demand, business risks and capability of each service to supply against that demand dja@djaa.com, @djaa_dja
  21. 21. Kanban Method Uses visualization of invisible work and virtual kanban systems Installs evolutionary ‚DNA‛ in your organization Enables adaptability to respond successfully to changes in your business environment dja@djaa.com, @djaa_dja
  22. 22. 6 Practices for Evolutionary DNA The Generalized Version Visualize Limit Work-in-progress Manage Flow Make Policies Explicit Implement Feedback Loops Improve Collaboratively, Evolve Experimentally (using models & the scientific method) dja@djaa.com, @djaa_dja
  23. 23. Kanban Kata dja@djaa.com, @djaa_dja
  24. 24. Feedback Loops The Kanban Kata Operations Review Improvement Kata Standup Meeting dja@djaa.com, @djaa_dja
  25. 25. Standup Meeting Disciplined conduct and acts of leadership lead to improvement opportunities Kaizen events happen at after meetings dja@djaa.com, @djaa_dja
  26. 26. Improvement Kata A mentor-mentee relationship Usually (but not always) between a superior and a sub-ordinate A focused discussion about system capability Definition of target conditions Discussion of counter-measures – actions taken to improve capability dja@djaa.com, @djaa_dja
  27. 27. Operations Review Meet monthly Disciplined review of demand and capability for each kanban system Provides system of systems view and understanding Kaizen events suggested by attendees dja@djaa.com, @djaa_dja
  28. 28. Scaling out across an organization dja@djaa.com, @djaa_dja
  29. 29. Treat each service separately Demand Observed Capability Demand Observed Capability Demand Observed Capability dja@djaa.com, @djaa_dja
  30. 30. Some systems have dependencies on others Demand Observed Capability Demand Observed Capability Demand Observed Capability dja@djaa.com, @djaa_dja
  31. 31. Organizational Improvements Emerge dja@djaa.com, @djaa_dja
  32. 32. Scaling Kanban Each Kanban System is designed from first principles around a service provided Scale out in a service-oriented fashion Do not attempt to design a grand solution at enterprise scale The Kanban Kata are essential! Allow a better system of systems to emerge over time dja@djaa.com, @djaa_dja
  33. 33. Scaling up and down (big projects, portfolios & personal work) dja@djaa.com, @djaa_dja
  34. 34. Scaling Up - Planning a big project 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 (local average) delivery rate 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, @djaa_dja
  35. 35. 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, @djaa_dja WIP
  36. 36. 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, @djaa_dja Treat as a fixed variable
  37. 37. 2-tiered board Kanban System within a Kanban System 1 lane per team dja@djaa.com, @djaa_dja
  38. 38. 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, @djaa_dja
  39. 39. Scaling Down - Personal Kanban A mutation that emerged in my office in 2008 by Jim Benson & Corey Ladas For individuals & small teams (2 or 3 ppl) Visualize Limit WIP Simple To Do-Next-Doing-Done boards dja@djaa.com, @djaa_dja
  40. 40. Scaling Up - Portfolio Kanban Another mutation that emerged in 2009 in various places such as mobile.de in Berlin Focus on limiting projects in a portfolio No real workflow Visualize project completion through physical position of ticket Visualize business risks dja@djaa.com, @djaa_dja
  41. 41. Hedging Investment Risk against Product Lifecycle in a Portfolio Kanban Horizontal position shows percentage complete Allocation of personnel Total = 100% Complete 0% Cash Cows 10% budget Size of ticket indicates scale or size of project D C K E G F dja@djaa.com, @djaa_dja Complete 100% B A Growth Markets 60% budget Innovative/New 30% budget Projects-in-progress Color may indicate cost of delay (or other risk) H
  42. 42. Thank you! dja@djaa.com, @djaa_dja
  43. 43. 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, @djaa_dja
  44. 44. Acknowledgements Hakan Forss of Avega Group in Stockholm has been instrumental in defining the Kanban Kata and evangelizing its importance as part of a Kaizen culture. Real options & the optimal exercise point as an improvement over ‚last responsible moment‛ emerged from discussions with Chris Matts, Olav Maassen and Julian Everett around 2009. The inherent need for evolutionary capability that enables organizational adaptation was inspired by the work of Dave Snowden. dja@djaa.com, @djaa_dja
  45. 45. David J Anderson & Associates, Inc. dja@djaa.com, @djaa_dja
  46. 46. Appendix dja@djaa.com, @djaa_dja
  47. 47. dja@djaa.com, @djaa_dja Fixed Date Intangible Standard Expedite Example Distributions
  48. 48. dja@djaa.com, @djaa_dja

×