Nick Oostvogels: 5 Arguments Against Kanban
2 likes2,071 views
Kanban faces several common arguments against its adoption. These include concerns that Kanban will: 1) Limit the ability to plan work. 2) Cause work to take longer to complete. 3) Result in work getting stuck if work-in-progress limits are enforced. 4) Not align with stakeholder priorities if they do not consider flow. 5) Reduce team cohesion by focusing on individual tasks rather than collaboration.
Nick Oostvogels: 5 Arguments Against Kanban
- 1. 5 ARGUMENTS against KANBAN @NickOostvogels
- 2. Kanban is on the rise Source : VersionOne -‐ State of Agile Survey 2011
- 3. When introducing new ideas… h"p://www.flickr.com/photos/smannion/3385144016/
- 4. People compare it to what they know h"p://www.flickr.com/photos/mvjantzen/4815422633/
- 5. … and start to criticize h"p://www.flickr.com/photos/the-‐g-‐uk/3913466332/
- 6. Kanban is hard to explain briefly h;p://www.flickr.com/photos/digitalmums/6310508350/
- 7. That’s normal • Kanban is a change management approach, not a process • Less prescriptive • It’s roots go all the way back to lean thinking
- 8. What is Kanban? In Industry hp://www.flickr.com/photos/scania/2869199313/
- 9. In Software Development Change Management approach that employs a WIP limited pull system hp://www.flickr.com/photos/adelcambre/2768856149/
- 10. 1. Start with what you now 2. Agree to pursue incremental, evolutionary change 3. Initially, respect current roles, responsibilities job titles Source : limitedwipsociety.org
- 11. then adopt the core practices 1. Visualize 2. Limit Work In Progress 3. Manage Flow 4. Make Process Policies Explicit 5. Improve Collaboratively Source : limitedwipsociety.org
- 12. For me … Kanban is a way to change your process into one that focuses on end to end value and getting stuff delivered.
- 13. And that’s hard to sell !
- 15. 5 tough questions hp://www.flickr.com/photos/40358860@N04/4250860618/
- 16. 1. we lose our ability to plan hp://www.flickr.com/photos/40358860@N04/4250860618/
- 17. No estimates? hp://www.flickr.com/photos/photojonny/2268845904/
- 19. estimates are used to decide hp://www.flickr.com/photos/ol1/4605912815/
- 20. we manage people by estimates hp://www.flickr.com/photos/lambdachialpha/3795728748/
- 21. Typical Release planning Translation into Initial requirements specs Estimation Review Release estimations Plan
- 22. Issues of software development • Not a repeatable process • Never built something alike • (educated) GUESSING
- 24. Different sizes ??? hp://www.flickr.com/photos/jaydedman/2593673396/
- 25. Use a scale compare
- 26. Standard size
- 27. Why sizing? hp://www.flickr.com/photos/lawdeda/4094259672/
- 29. Reduce variation 1. Working with averages must be reliable 2. Fast response 3. Base for continuous improvement
- 30. Small releases Kanban != continuous deployment
- 31. Small releases Kanban can lead to continuous deployment
- 32. Won’t this annoy our users? hp://www.flickr.com/photos/photojonny/2268845904/
- 33. Small releases NO, because… • Updates will be smaller • Risk for bugs is lower + Releasing early creates a sense of urgency
- 34. options for Re-planning 1. Reprioritize the input queue 2. Cadence 3. Pull a planning meeting
- 35. 2. it will take longer hp://www.flickr.com/photos/40358860@N04/4250860618/
- 37. Parkinson’s law “The amount of time which one has to perform a task … … is the amount of time it will take to complete the task.”
- 38. From a cost perspective From a value perspective From an HR perspective
- 39. Healthy balance in Kanban Managing by measuring http://www.flickr.com/photos/wok_design/2499217405/
- 40. Healthy balance in Kanban Helping to improve instead of command control http://www.flickr.com/photos/wok_design/2499217405/
- 41. Theory of Constraints for process improvement http://www.flickr.com/photos/96dpi/3371440496/
- 42. the weakest chain determines the rate of the entire system
- 43. the WIP Limits will let you feel the TOC and do something about it
- 44. Flow • Only work on customer orders • Reduce guessing to avoid waste • Limit WIP to reduce inventory, cost risk hp://www.flickr.com/photos/23945877@N05/2623633694/
- 45. WIP limits create a pull system
- 46. Isn’t this inefficient? hp://www.flickr.com/photos/photojonny/2268845904/
- 47. NO, it reduces risk waste! • The risk of starting something that doesn’t match expectations • The risk of declining value
- 48. 3. Things will get stuck, we can’t keep WIP limits! hp://www.flickr.com/photos/40358860@N04/4250860618/
- 49. “Our testers can never keep up the pace of our developers. Developers would be idle for half of the time!” hp://www.flickr.com/photos/wheaKields/4774087006/
- 50. Remember: Kanban doesn’t focus on maximizing utilization of people
- 51. End to end flow efficiency hp://www.flickr.com/photos/serdar/125457544/
- 52. WIP limits will always cause bottlenecks That’s a good thing! It drives continuous improvement towards end to end efficiency
- 53. Being idle due to uneven flow distribution drives people crazy! h;p://www.flickr.com/photos/annayanev/3491617954/
- 54. Ex. 1 - Requirements
- 55. Ex. 2 - Defects
- 56. Ex. 3 - Deployment
- 57. Ex. 4 - Emergencies
- 58. Ex. 4 - Emergencies
- 59. Collaboration is a cure for bottlenecks
- 60. 4. Stakeholders don’t care about feeding the flow hp://www.flickr.com/photos/40358860@N04/4250860618/
- 61. Prioritization doesn’t have to be on a task level
- 62. Clear rules make prioritization easier • What is the type of feature? (new, bug, enhance- ment, ...) • What is the business value? • What is the cost of delay and which type? • Any dependencies on other features? • …
- 63. it forces stakeholders to do their homework! hp://www.flickr.com/photos/cayusa/2194119780/
- 64. Encourages building an MVP Stakeholders care about Return on Investment hp://www.flickr.com/photos/59937401@N07/5929491095/
- 66. Stop relying on status reports Visual progress instead
- 67. focus on economic decisions instead of fighting for capacity hp://www.flickr.com/photos/jpeepz/6236688/
- 68. 5. we will lose team cohesion hp://www.flickr.com/photos/40358860@N04/4250860618/
- 69. Won’t the team turn into factory workers? hp://www.flickr.com/photos/psit/5207166416/
- 70. WIP limits lead to cross-boundary communication
- 71. Good teams have a common goal hp://www.flickr.com/photos/atomicshed/161716498/
- 72. Good teams have a common goal Vertically organized companies lead to teams with conflicting goals hp://www.flickr.com/photos/atomicshed/161716498/
- 73. in Kanban, everybody contributes to the end 2 end process hp://www.flickr.com/photos/saamiam/4203685689/
- 74. this is a powerful change management approach • no theoretical frameworks • no new job descriptions • only some basic rules
- 75. What about creative thinking? hp://www.flickr.com/photos/photojonny/2268845904/
- 76. The focus on improving flow stimulates creativity • Team will start to investigate • Limit back-cycles • Lead Cycle time measuring stimulates close collaboration
- 77. Won’t it cause a death march? hp://www.flickr.com/photos/photojonny/2268845904/
- 78. Measurements are used to understand reality have a base for improvement hp://www.flickr.com/photos/usnavy/6083504722/
- 79. Not pushing to go faster but improving end 2 end hp://www.flickr.com/photos/rwp-‐roger/3854246685/
- 80. Now you have a response! 1. We lose our ability to plan 2. It will take longer 3. Things will get stuck 4. Stakeholders don’t care about feeding the flow 5. We will lose team cohesion
- 82. 6. Software development is not manufacturing! hp://www.flickr.com/photos/40358860@N04/4250860618/
- 83. Kanban has it’s roots in the Toyota Production System That’s why it feels so right for support teams.
- 84. It feels different in product development
- 85. not all lean manufacturing principles are valid for product development hp://www.flickr.com/photos/chrism70/104302940/
- 86. Instead fast feedback loops are more interesting Removing waste by truncating a bad path quickly
- 87. Product development characteristics: • creative thinking • continuous testing of new ideas • seeking as much feedback as possible • intense discussions
- 88. Lean product development: • Strong leadership • Cross-functional teams • Set-Based Concurrent Engineering • Short feedback loops • Focus on the customer and supplier • Cadence, Pull, and Flow
- 89. The application differs in Lean • Product development • Manufacturing The same way it differs in Kanban for • Software development • Support operations
- 90. Nevertheless they are built on the same principles!