Kanban explained David Anderson LAS 2011-zurich


Published on

Kanban is a technique that was elaborated in the manufacturing industry for years. But it also works nicely for knowledge work such as project development. Especially evolutionary change management in IT organizations lends itself perfectly to the Kanban field.

David J. Anderson speaking about Kanban at the LAS Conference 2011 in Zurich.

Read the summary on my blog at http://t.co/Mr7Be9T

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

Kanban explained David Anderson LAS 2011-zurich

  1. 1. Kanban Explained!A counter-intuitive approach to creatinga Lean Organization<br />David J. Anderson LAS 2011Zurich, September 2011<br />
  2. 2. Published April 2010<br />A 72,000 word introduction<br />More to come in a future book<br />
  3. 3. Published in GermanJanuary 2011<br />Translation byArne Roock & Henning Wolfof IT-Agile<br />
  4. 4. What is…Lean Software Development?<br />
  5. 5. The foundational pillars of Lean are debated by different authors, however, most would agree on the following…<br />
  6. 6. Pillars of Lean<br />Value<br />Value Stream<br />Flow<br />Pull<br />Continuous Improvement<br />Respect for People<br />Holistic Process Approach(aka. Systems Thinking)<br />
  7. 7. Western Lean Thinking has focused on waste elimination in comparison with Japanese “Toyota Way” that has a broader definition of muda, muri and mura, and a cultural aspect Kaizen<br />
  8. 8. Western Lean literature and consulting tended to focus on waste elimination. This was both easy to do and useful in manufacturing but has proven problematic in knowledge work areas.<br />
  9. 9. The concept of Lean Software Development has been around since 1993, and yet by 2008 you didn't meet anyone doing it<br />
  10. 10. Agile Management in 2003<br />Introduced some Lean ideas including the synthesis of Flow, Visualization using Cumulative Flow Diagrams &Bottleneck Management<br />
  11. 11. I’d been talking about managing flowfor 6 years, but despite support for cumulative flow diagrams in many Agile tools, (almost) no one was doing it!<br />
  12. 12. I concluded that after 15+ years we must assume that Growing Lean Adoption in the IT industry ishard!<br />
  13. 13. Agile Methods are not creating Lean Organizations …<br />
  14. 14. Extreme Programming is evidently a veryLeanmethod<br />
  15. 15. XP has very little waste<br />
  16. 16. TPS divides waste into 3 types<br />Muda – non-value added tasks<br />Muri – unevenness (or variability) in flow<br />Mura – overburdening<br />
  17. 17. XP avoidsMurathrough use of tests and tight definition of "Done"<br />
  18. 18. XP avoidsMuriwith skilled craftsmanship that can "flow" a story without handoffs and a strict WIP limit policy of1 story per pair<br />
  19. 19. XP has littleMudaas planning, coordination and delivery are lightweight and partly automated<br />
  20. 20. Some XP practitioners such asJoshua Kerievsky, ArloBelshee & Jim shorehave sought to reduce waste in XP with techniques such as Naked Planning, Agile Workcell, elimination of planning, estimation and time-boxed iterations, and Limited Red<br />
  21. 21. Themotivationfor these changes, that involved introduction of "kanban" style techniques, was (further)elimination of waste<br />
  22. 22. However, Extreme Programming hasn't been for everyone!<br />
  23. 23. Some people & organizations have resistedadoption of Agile methods!<br />
  24. 24. If not every organization is ready to adoptan Agile method, how can we encourage them to become more Lean?<br />
  25. 25. So What is the Kanban Method?<br />
  26. 26. Kanban is the enabler of a Kaizen Culture & emergence of a Lean organization<br />
  27. 27. So how do we go about introducing Lean into organizations that have failedto adopt an Agile method such as TDD or failed to truly achieve a continuously improving culture?<br />
  28. 28. The counter-intuitive answeris to use apull system that limitswork-in-progress as a catalyst for introduction of other Lean concepts<br />
  29. 29. Kanban Systems are pull systems that limit work-in-progress and have been part of the Lean toolkit for 50+ years <br />
  30. 30. Mymotivationfor adopting kanban systems was toprevent mura, control muriand encourage an evolutionary approach to change<br />
  31. 31. In developing theKanban Method, a change management approach that uses kanban systems to provoke change, we are enabling the emergenceof Lean software development in organizations<br />
  32. 32. How does theKanban Method work?<br />
  33. 33. Kanban is based on 3 principles<br />Start with what you do now<br />Agree to pursue incremental, evolutionary change<br />Initially, respect current processes, roles, responsibilities & job titles<br />
  34. 34. Then…<br />adopt the 5 core practices that are observedto be present in successful Kanban implementations<br />
  35. 35. 5 core practices for successful Kanban adoption<br />Shallow<br />Visualize Workflow<br />Limit Work-in-Progress<br />Manage Flow<br />Make Process Policies Explicit<br />Improve Collaboratively(using models & scientific method)<br />Depth<br />Deep<br />
  36. 36. It’s not a question of right or wrong …<br />Shallow<br />It’s a question of shallow or deep!Shallow implementations tend to produce fewer, less dramatic results<br />Depth<br />Deep<br />
  37. 37. When…<br />all5 core practices are adopted they form the seed conditions for Kanban as a complex adaptive systemthat enables a Lean(er) way of working to emerge<br />
  38. 38.
  39. 39. Visualize Workflow<br />
  40. 40. Limit Work-in-Progress<br />3<br />20<br />2<br />4<br />
  41. 41. Observe Flow (empty test column)<br />
  42. 42. ObserveFlow with a CFD<br />Avg. Lead Time<br />WIP<br />
  43. 43. ObserveFlow with a lead time control chart<br />
  44. 44. Observe Flow with a spectral analysis histogram of lead time<br />SLA of51 dayswith 98% on-timea from mean)<br />
  45. 45. Development is a Bottleneck<br />This is an example of using a model to identify an improvement opportunity<br />
  46. 46. Analysis is overloaded<br />Analysis suffers from non-instant availability of subject matter experts / business owners<br />
  47. 47. Couple observation of non-instant availability of expertise with visual & quantitative evidence of muri in flow to encourage better availability<br />
  48. 48. Conversation & Leadership<br />
  49. 49. Leadership is the magic ingredient<br />sprinkle liberally over the 5 seed properties<br />
  50. 50. The WIP limit provokes the conversation<br />
  51. 51. Without a WIP limit the Idle & Stuck comments may never emerge<br />
  52. 52. The team has a choice to break the WIP limit and ignore the issues, or face up to the issues and address them using the models<br />
  53. 53. The WIP limit simply provokes the conversation. <br />Leadership encourages discussion about improvement. Use of Models and other evidence leads to an improvement suggestion and implementation<br />
  54. 54. Kanban & Emergence<br />
  55. 55. Emergent behavior is seen in nature when systems adapt to unfolding events and changing circumstances in their surroundings<br />
  56. 56. Often very complex behavior is derived out of system with simple rules. When these rules can change over time, the systems are referred to as Complex Adaptive Systems<br />
  57. 57. Kanban has been observed to stimulateemergent behaviors in many organizations<br />
  58. 58. The simple rules of Kanban such as WIP limits, Cadence, Pull Criteria & Classes of Service, are adaptable over time. Hence, Kanban creates a Complex Adaptive System within an organization<br />
  59. 59. This explains why Kanban provides a good mechanism for dealing with complexity in knowledge work processes<br />
  60. 60. There is a growing list of emergent behaviors observed in practice<br />Process uniquely tailored to each project/value stream <br />Decoupled Cadences (aka Iterationless Development)<br />Work Scheduled by (opportunity) Cost of Delay <br />Value Optimized with Classes of Service<br />Risk Managed With Capacity Allocation<br />Tolerance for Process Experimentation<br />Quantitative Management<br />Viral Spread (of Kanban)<br />Small teams merged for more liquid labor pools<br />
  61. 61. TypicallyNoEnterprise Process DefinitionNo "shrink to fit.“Nor is there "stretch to fit.“The existing process evolves over time and emerges as a new leaner process, based on simple rules and operational performance models.<br />
  62. 62. Iterationless Flow is acommon motivation for adopting the use of a kanban systemHowever, it is not core to the Kanban Method for change managemente.g. you can add a kanban system to Scrum and provoke evolutionary change without abandoning Sprints<br />
  63. 63. A WIP limit on the input queue focuses attention on what to start nextProvokes focus on value(market payoff function, aka cost of delay function)<br />
  64. 64. Sketching a market payoff function to visualize cost of delay is easier than asking for an absolute value<br />Room Nights <br />Desired Release Date<br />Cost of delay for an online Easter holiday marketing promotion for a hotel chain is visualized as the difference in integral under two curves<br />
  65. 65. Example classes of service<br />Expedite<br />Fixed Delivery Date<br />Significant delay incurred on or from a specific date in near future<br />Standard Class<br />(Near) linear cost of delay beginning immediately<br />Intangible Class<br />No tangible cost of delay within reasonable lead time to delivery window<br />
  66. 66. Allocate capacity across classes of service mapped against customer demand<br />5<br />4<br />3<br />= 20 total<br />4<br />2<br />2<br />Analysis<br />Development<br />...<br />InputQueue<br />DevReady<br />ReleaseReady<br />BuildReady<br />In Prog<br />In Prog<br />Done<br />Done<br />Test<br />Allocation<br />+1 = +5%<br />4 = 20%<br />10 = 50%<br />6 = 30%<br />
  67. 67. Quantitative Management where data is used to drive improvement (change) decisions<br />Majority of CRs range 30 -> 55<br />Outliers<br />Ignore outliers and makes changes to shorten lead times on typical (common cause) work<br />
  68. 68. Some early examples of viral spread<br />Corbis<br />Process team, Dictionary team, BI team, upstream BAs<br />IPC Media<br />5 teams<br />BBC<br />BBC Worldwide 1 to 7 teams, BBC PBS now at least 11 teams<br />Vanguard<br />Spread across 4000 person organization<br />ASR<br />From 1 team to 18 teams<br />
  69. 69. Merged teams share members across swim lanes<br />LKBE10<br />
  70. 70. Conclusions<br />
  71. 71. Limiting work-in-progress can catalyzeincremental changes<br />
  72. 72. The team must respectthe WIP limit and value the conversationsit provokes about problems<br />
  73. 73. Leadershipis the secret sauce! Encourage it from any team member regardless of position, experience or authority<br />
  74. 74. Arm the team with transparency of process(visualization of workflow and explicitly stated policies.) Use models for understanding problems and improvementswill occur.<br />
  75. 75. These improvements will provide bettereconomic and sociological outcomes<br />
  76. 76. What emerges is an organization that lives all the pillars of Lean<br />
  77. 77.
  78. 78. Thank you!<br />dja@djandersonassociates.com<br />http://www.kanbaninaction.com/<br />
  79. 79. http://leankanbanuniversity.com<br />http://www.limitedwipsociety.org<br />LinkedIn Groups: Software Kanban<br />Yahoo! Groups: kanbandev<br />Yahoo! Groups: kanbanops<br />
  80. 80. About…<br />David Anderson is a thought leader in managing effective software teams. He leads a consulting firm dedicated to improving economic performance of knowledge worker businesses – improving agility, reducing cycle times, improving productivity and efficiency in technology development.<br />He has 25+ years experience in the software industry starting with computer games in the early 1980’s. He has led software teams delivering superior productivity and quality using innovative agile methods. He developed MSF for CMMI Process Improvement for Microsoft. He is a co-author of the SEI Technical Note, CMMI and Agile: Why not embrace both!<br />David is the author of 2 books, Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results, and Kanban – Successful Evolutionary Change for your Technology Business.<br />David is a founder of the Lean Software & Systems Consortium, a not for profit dedicated to promoting greater professionalism and better economic outcomes in our industry. Email… dja@djandersonassociates.com<br />