David anderson kanban when is it not appropriate

7,401 views

Published on

Published in: Business, Technology

David anderson kanban when is it not appropriate

  1. 1. David J. Anderson Lean Kanban Benelux October 2011 When is it not appropriate? Kanban
  2. 2. Understanding Options for Improvement
  3. 3. Goals for using Kanban Economically balancecapability against demand
  4. 4. Available options
  5. 5. Risk Management is anEnabling Capability…
  6. 6. Tools For RiskManagement…
  7. 7. Most processgeeks & ITmanagers areoperating overhere
  8. 8. Kanban is encouraging collaborativeconversations with other stakeholdersto open up options for improvement over here
  9. 9. Foundations of the Kanban Method
  10. 10. Variability in Flow My motivation for adopting kanban systems was toprevent muri, control muraand encourage an evolutionary approach to changeOverburdening
  11. 11. Appropriateness Question #1Does your process suffer from overburdening or variability in flow?
  12. 12. What causes unevenness?1. Non-instant availability of specialist skills or collaborators2. Information fails to arrive before it is needed3. Hidden/Implicit classes of service that cause work to be interrupted to process other work4. Variety in work (complexity & size)5. Changing priorities related to variety in risks associated with work (e.g. cost of delay)6. Capacity constrained specialist skilled workers or other resources (e.g. test environments)
  13. 13. Are any of these present in your work environment?
  14. 14. Kanban may be appropriate for you!
  15. 15. Kanban is unnecessary where demand never exceeds capability and flow is smooth and never interrupted! If conditions of overburdening or unevenness in flow exist or are likely to then use of a kanban system may be an appropriate choice
  16. 16. In developing theKanban Method, a change management approach that useskanban systems to provoke change, we are enabling theemergence of Lean software development in organizations
  17. 17. The Kanban approach to change is based on 3 principles1. Start with what you do now2. Agree to pursue incremental, evolutionary change3. Initially, respect current processes, roles, responsibilities & job titles
  18. 18. Then…adopt the 5 core practices that are observed to be present in successful Kanban implementations
  19. 19. 5 Core Practices for Successful Kanban Adoption Shallow1. Visualize2. Limit Work-in-Progress Depth3. Manage Flow4. Make Process Policies Explicit5. Improve Collaboratively (using models & scientific method) Deep
  20. 20. Doing Kanban is not a question ofright or wrong … Shallow It’s a question of shallow or deep! Depth Shallow implementations tend to produce fewer, less dramatic results Deep
  21. 21. When…all 5 core practices are adopted theyform the seed conditions for Kanban complex adaptive as a system that enables a Lean(er) way of working to emerge
  22. 22. Kanban & the Cynefin Framework
  23. 23. Observation shows mura & muri arepresent respond with a kanban system
  24. 24. Process is defined No feedback loop required Implemented in a single transition
  25. 25. Core practices of Kanban reveal problemsrespond with a kaizen event
  26. 26. Scale may require multiple dependent kanban systems Use of risk profilingand classes of service
  27. 27. Process improves incrementallyFeedback loop required Use of existing models Highly predictableimprovement outcomes
  28. 28. Use policies tocreate a containerwithin the kanbansystem design tocontrol complexemergent behavior
  29. 29. Change kanbansystem design(policies) to catalyze(or probe) for desiredemergent outcomes
  30. 30. Use visualization &metrics to reflect onoutcomes, newmodels emerge,complexity is reduced
  31. 31. Complex adaptivesystems -independent agentsfollowing simple rulesFeedback loopsSimple rules change
  32. 32. Kanban -Simple rules madevisual & explicitFeedbackKaizen events –adapt the rules
  33. 33. Systems (such as softwaredevelopment systems) exist in all 3 domainssimultaneously
  34. 34. Kanban is designed to work in all 3 domains simultaneously
  35. 35. Kanban is unlikelyto be useful in theChaotic domain orin presence ofdisorder
  36. 36. Kanban & Corporate Culture
  37. 37. Is your new CTO a revolutionary?
  38. 38. Not every senior leader is arevolutionary
  39. 39. But many feel the need to shake thingsup and leave their mark Carly Fiorina
  40. 40. Your boss may lack the patience to wait for an incremental approach to improvement to take effect
  41. 41. Kanban & the Spectrum of Work
  42. 42. Kanban’s Roots
  43. 43. Kanban’s Roots Some say Kanban’s decoupled cadences (no time-boxed iterations) and single-piece flow should make it a natural fit for this space!
  44. 44. Kanban’s Roots As decoupled cadences and single-piece flow have little benefit in thisspace, it stands to reason Kanban is not useful here!
  45. 45. Kanban’s Roots To think this way is to look As decoupled cadences Some say Kanban’s and single-piece flow at decoupled cadences (no simplistically Kanban as a process implementation for have little benefit in this time-boxed iterations)space, it stands to reason single-piece transactional and single-piece flow Kanban work.useful is not To treat shoulda point a natural it as make it solution to a specific for this space! here! fit problem (within the Simple domain)
  46. 46. Kanban’s Roots It misses the point that As decoupled cadences Some say Kanban’s kanban systems do not and single-piece flow decoupled cadences (no have little benefit in this as processiterations) stand alone time-boxed solutions. A kanban systemspace, it stands to reason and single-piece flow Kanban issomething that is overlaid natural is not useful should make it a here! an existing process space! on fit for this
  47. 47. The metric most usefulchanges at different ends of this spectrum
  48. 48. Ideally move more work this way Make batch size smaller
  49. 49. A nice mix of work from which we’vebeen able to learna lot about kanban system design
  50. 50. Leading to emergent designs with classes of service and capacity allocation 5 4 3 4 2 2 = 20 totalAllocation Input Analysis Dev Development Build Release ...Total = 20 Queue In Prog Done Ready In Prog Done Ready Test ReadyChange Req[12]Sev 1 Defect (Expedite)[2]Sev 2 – 5 Defect[6]
  51. 51. Simple & complicated domain application ofkanban systems.Some doubts as to the value ofWIP limits & pull systems
  52. 52. Application ofKanban Method across Simple,Complicated and Complex domains
  53. 53. Lots of enthusiasm! Mechanics of decoupledNatural territory cadences & for Kanban single-piece flow are seductive But maybe not ideal territory for Kanban
  54. 54. Conclusion
  55. 55. KanbanFor broad application as a process overlay to control “mura” and eliminate “muri” in the simple/complicated domain For broad application as a process overlay and catalyst of process improvement in the simple, complicated & complex domainsMost useful where demand can be treated as a pool of options and can be shaped using risk management, marketing strategy and strategic planning
  56. 56. Kanban Domain need for single-piece flow or decoupling of planning, lead time, and delivery; Or, application to short-order transactionalwork with small batch size and high frequency delivery are Red Herrings! Kanban works for Major Projects!
  57. 57. Kanban is for evolutionaries Kanban maybe just what I need! I don’t have time for this! Kick ass, take names & get it done! Carly Fiorina
  58. 58. Thank you! dja@djandersonassociates.com http://www.kanbaninaction.com/
  59. 59. About…David Anderson is a thought leader inmanaging effective software teams. He leadsa consulting firm dedicated to improvingeconomic performance of knowledge workerbusinesses – improving agility, reducingcycle times, improving productivity andefficiency in technology development.He has 25+ years experience in the softwareindustry starting with computer games in theearly 1980’s. He has led software teamsdelivering superior productivity and quality usinginnovative agile methods. He developed MSFfor CMMI Process Improvement for Microsoft.He is a co-author of the SEI Technical Note,CMMI and Agile: Why not embrace both!David is the author of 2 books, AgileManagement for Software Engineering –Applying the Theory of Constraints for BusinessResults, and Kanban – Successful EvolutionaryChange for your Technology Business.David is a founder of the Lean Software &Systems Consortium, a not for profit dedicatedto promoting greater professionalism and bettereconomic outcomes in our industry. Email…dja@djandersonassociates.com

×