Kanban VS Scrum


Published on

Presentation from IT Jam conference (Kiev 2009) about basics of Kanban process and comparison analysis of Scrum and Kanban.

Published in: Technology, Business
No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Kanban VS Scrum

  1. 1. Kanban VS Scrum Alimenkou Mikalai 31.10.2009
  2. 2. Agenda <ul><li>Introduction to Kanban </li></ul><ul><li>Kanban main principles </li></ul><ul><li>Example from Kanban-land </li></ul><ul><li>When apply/not apply Kanban? </li></ul><ul><li>Comparison of Scrum and Kanban </li></ul>
  3. 3. What is a Kanban? A  Kanban is a physical card used in Toyota Production System (TPS) to support non-centralized &quot;pull&quot; production control. It has spread to the manufacturing industry all over the world as a tool of Lean Manufacturing . &quot; Kan &quot; means visual, and &quot; ban &quot; means card or board .
  4. 4. Kanban Practices <ul><li>Map the Value Stream </li></ul><ul><li>Visualize the Work </li></ul><ul><li>Limit Work in Progress </li></ul><ul><li>Establish a Cadence </li></ul><ul><li>Enable continuous improvement </li></ul>
  5. 5. Kanban Board Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  6. 6. Limiting Work in Progress <ul><li>Reduce multi-tasking </li></ul><ul><ul><li>Prevent context switching </li></ul></ul><ul><ul><li>Performing tasks sequentially yields results sooner </li></ul></ul><ul><li>Maximize throughput </li></ul><ul><li>Enhance teamwork </li></ul><ul><ul><li>Working together to make things done </li></ul></ul><ul><ul><li>Increase cross-functionality </li></ul></ul>
  7. 7. Pull, Don’t Push
  8. 8. WIP Limit Strategy <ul><li>Start with some initial value </li></ul><ul><ul><li>Small constant (1-3) </li></ul></ul><ul><ul><li>Number of developers </li></ul></ul><ul><ul><li>Number of testers </li></ul></ul><ul><li>Measure the cycle time </li></ul><ul><ul><li>Average time of one piece full cycle flow </li></ul></ul><ul><li>Change limit to decrease cycle time </li></ul>
  9. 9. Idle Team Members Guide <ul><li>Can you help progress and existing kanban? – Work on that. </li></ul><ul><li>Don’t have the right skills? – Find the bottleneck and work to release it. </li></ul><ul><li>Don’t have the right skills? – Pull in work from the queue. </li></ul><ul><li>Can’t start anything in the queue? – Check if there any lower priority to start investigating. </li></ul><ul><li>There is nothing lower priority? – Find other interesting work (refactoring, tool automation, innovation). </li></ul>
  10. 10. What is Cadence? “ A regular cadence, or heartbeat, establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity. ”
  11. 11. Kanban Metrics <ul><li>Stories in progress ( SIP ) </li></ul><ul><li>When story enters stories queue set entry date ( ED ) </li></ul><ul><li>When story enters first process step set start processing date ( SPD ) </li></ul><ul><li>When story is done set finish date ( FD ) </li></ul><ul><li>Cycle time ( CT ) = FD – SPD </li></ul><ul><li>Waiting time ( WT ) = SPD – ED </li></ul><ul><li>Throughput ( T ) = SIP / CT </li></ul>
  12. 12. Workflow Diagram
  13. 13. 5 Wrong Reasons to Apply Kanban <ul><li>User stories diversity </li></ul><ul><ul><li>User stories vary in size a lot, large stories don’t feet into an iteration </li></ul></ul><ul><li>Failed iterations </li></ul><ul><ul><li>Many stories are not completed in a single iteration </li></ul></ul><ul><li>Failed retrospective meetings </li></ul><ul><ul><li>Retrospective meetings are waste </li></ul></ul><ul><li>Shared people </li></ul><ul><ul><li>We have a single pool of developers for some projects </li></ul></ul><ul><li>Simplicity </li></ul><ul><ul><li>Kanban is so simple, no planning, no retrospectives, no estimations </li></ul></ul>
  14. 14. 5 Right Reasons to Apply Kanban <ul><li>Ability to release anytime </li></ul><ul><ul><li>When user story is ready you may release it </li></ul></ul><ul><li>Ability to change priorities on the fly </li></ul><ul><ul><li>Not started stories queue is always changeable </li></ul></ul><ul><li>No need in iterations </li></ul><ul><ul><li>Iterate first then flow </li></ul></ul><ul><li>No need to estimate </li></ul><ul><ul><li>Release when it is ready, do most important story </li></ul></ul><ul><li>Perfect flow visualization </li></ul><ul><ul><li>Clear view of current work in progress </li></ul></ul>
  15. 15. When no Need in Iterations? <ul><li>Support project </li></ul><ul><li>Bug fixing stage </li></ul><ul><li>All valuable stories are too large and can’t be divided </li></ul><ul><li>Testing can’t be finished in iteration so quality suffers </li></ul><ul><li>Team is self-organizing and trusted enough to work without iterations </li></ul><ul><li>No backlog ready for iteration planning </li></ul>
  16. 16. When no Need to Estimate? <ul><li>You are new to the project </li></ul><ul><li>Estimations don’t change plans </li></ul><ul><li>Velocity is not taken into account </li></ul><ul><li>Team is very experienced in breaking tasks </li></ul><ul><li>Average cycle time is enough for the customer </li></ul>
  17. 17. Example from Kanban-land 1 2 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  18. 18. Example from Kanban-land 3 4 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  19. 19. Example from Kanban-land 5 6 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  20. 20. Example from Kanban-land 7 8 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  21. 21. Example from Kanban-land 9 10 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  22. 22. Example from Kanban-land 11 12 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  23. 23. Kanban for Product Owners <ul><li>New </li></ul><ul><ul><li>Prioritized buffer </li></ul></ul><ul><ul><li>Unlimited size </li></ul></ul><ul><li>Preparing </li></ul><ul><ul><li>Work in Progress </li></ul></ul><ul><ul><li>Limited to PO capacity </li></ul></ul><ul><ul><li>Cycle time </li></ul></ul><ul><ul><li>Promotion model </li></ul></ul><ul><li>Ready </li></ul><ul><ul><li>Prioritized buffer </li></ul></ul><ul><ul><li>1-2 Team Velocity </li></ul></ul><ul><li>In Progress </li></ul><ul><ul><li>Work in Progress </li></ul></ul><ul><ul><li>Limited to Team WIP limit </li></ul></ul>
  24. 24. Kanban Best Practices <ul><li>Bugs get top priority </li></ul><ul><li>Set so minimal WIP as possible </li></ul><ul><li>Stories should be ”minimal marketable features” </li></ul><ul><li>Create separate column with goals </li></ul><ul><li>Add Scrum practices (daily scrum, retrospectives, demos) </li></ul><ul><li>Add XP engineering practices </li></ul>
  25. 25. User Stories Mapping
  26. 26. Kanban Issues <ul><li>Lack of goal and focus </li></ul><ul><li>Less predictability </li></ul><ul><li>Less commitment level </li></ul><ul><li>More discipline required </li></ul>
  27. 27. Scrum Overview
  28. 28. Kanban is Less Prescriptive Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  29. 29. Task Flow Scrum Kanban Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  30. 30. Project Cadence Scrum Kanban Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )
  31. 31. Scrum VS Kanban (Similarities) <ul><li>Both are Lean and Agile </li></ul><ul><li>Both use pull scheduling </li></ul><ul><li>Both limit WIP </li></ul><ul><li>Both use transparency to drive process improvement </li></ul><ul><li>Both focus on delivery releasable software early and often </li></ul><ul><li>Both are based on self-organizing teams </li></ul><ul><li>Both require breaking work into pieces </li></ul><ul><li>Both optimize release plan based on empirical data (velocity/cycle time) </li></ul>
  32. 32. Scrum VS Kanban (Differences)
  33. 33. Scrum VS Kanban (Differences)
  34. 34. Don’t Forget That … ANY process or methodology (that is not actively destructive), applied to a skilled, disciplined, high-functioning, motivated team, will succeed, regardless of the process. Likewise, any process applied to a low-functioning team will likely fail.
  35. 35. Resources <ul><li>http://availagility.wordpress.com/kanban - largest collection of Kanban related resources </li></ul><ul><li>http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html - Kanban detailed description </li></ul><ul><li>http ://www.lostechies.com/blogs/derickbailey/archive/2009/08/05/how-to-get-started-with-kanban-in-software-development.aspx - simple guide to start with Kanban </li></ul><ul><li>http://lizkeogh.com/2009/09/16/scrum-vs-kanban-fight - funny Scrum and Kanban dialog </li></ul><ul><li>http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf - great book from Henrik Kniberg </li></ul>
  36. 36. Any questions? Email me: [email_address] Read my blog: http://javadevelopmenttips.blogspot.com Visit my website: http://agilecoaching.com.ua