Successfully reported this slideshow.

From Scrum to Kanban


Published on

Switching my Scrum team to Kanban. Why we did it, how we did it and what we learned.

Published in: Technology, Business
  • Be the first to comment

From Scrum to Kanban

  1. 1. From Scrum to Kanban<br />Neil Johnson<br />
  2. 2. ScrumKanbanLessons Learned<br />
  3. 3. “The only thing that really matters is the quality of the team. Everything else is an optimisation.“<br />
  4. 4. ScrumKanban Lessons Learned<br />
  5. 5. Working environment<br />Software as a Service<br />Services sold on their reliability and availability<br />Industry is still very young, continual innovation is essential<br />Teams are cross functional<br />All members responsible for design, implementation, deployment and maintenance<br />Easy access to Product Development/Business<br />
  6. 6. Before Kanban we used Scrum (kinda)<br />Scrum practices<br /><ul><li>Time boxed iterations of 2 weeks
  7. 7. White board and post its to track status
  8. 8. Daily stand ups
  9. 9. Fortnightly retrospectives</li></ul>Not Scrum<br /><ul><li>Deploy multiple times an iteration
  10. 10. No formal product owner
  11. 11. No end of iteration demo</li></li></ul><li>What we liked about Scrum<br />A sense of rhythm and points to reflect on our working practices<br />Better visibility over tasks that were dragging on<br />A highly visible feedback loop to help improve our estimations<br />
  12. 12. Scrum was great but we had two problems with it….<br />
  13. 13. The iteration deadline felt artificial<br />No expectation from business of a post iteration demo<br />High dependence on outside parties<br />Frequently over/undershoot due to external dependencies<br />Time box limited choice of tasks in case of undershoot<br />
  14. 14. Not flexible enough mid iteration<br /><ul><li>A 2 weeks iteration promises, on average, a 3 week delay
  15. 15. The team is responsible for 2nd line support, operations and maintenance
  16. 16. We can assign a maintainer role to shield the team from day to day requests, though this is not always sufficient
  17. 17. Need a process that actively embraces the notion unplanned work</li></li></ul><li>ScrumKanbanLessons Learned<br />
  18. 18. Scrum vs Kanban comparison<br />In common:-<br /><ul><li>Both are Lean and Agile
  19. 19. Both use pull scheduling
  20. 20. Both use transparency to drive process improvement
  21. 21. Both focus on delivering working software as soon as possible</li></li></ul><li>Scrum vs Kanban comparison<br />Differences<br /><ul><li>Kanban less prescriptive than Scrum
  22. 22. Kanban does not prescribe fixed iterations
  23. 23. In Kanban Lead Time is the principle metric, in Scrum it is velocity
  24. 24. Kanban limits Work in Progress directly, Scrum does this indirectly through sprint planning</li></li></ul><li>Why Kanban?<br />Retain our discipline and structure<br />Limit work in progress rather than work per time<br />Improve responsiveness, through reduction in Lead Time<br />Can accommodate unexpected work without modifying the system<br />Always able to work on the next most important or risky task<br />
  25. 25. Kanban fundamentals<br />Visualise the workflow<br /><ul><li>Split the work down into small pieces
  26. 26. Represent each work item on a post it and put on the board
  27. 27. Use named columns to express where the work item is in the workflow</li></ul>Limit Work in Progress<br /><ul><li>Assign explicit limits to how many items may be in progress in each workflow state, or set of states</li></ul>Measure the lead time (average time to complete one item) <br /><ul><li>Optimise the process, aiming to make the Lead Time as small and as predictable as possible</li></li></ul><li>The Board<br />Should reflect your real working practices<br />Placement of the board is crucial<br />Work in progress limits drive behaviour<br />Start with loose, achievable limits and expect to fine tune<br />Expect the board to change state on a daily basis<br />
  28. 28. A simple example<br />
  29. 29. A more complicated example<br />
  30. 30. The post its<br />
  31. 31. How to measure lead time and optimise the process? <br />
  32. 32. Cumulative Flow Diagram<br />Aslak Hellesøy<br />
  33. 33. Lead Time<br />
  34. 34. ScrumKanban Lessons Learned<br />
  35. 35. Lessons Learned<br />Benefits<br /><ul><li>Greater flexibility in our work flow
  36. 36. We no longer feel that we are fighting our process
  37. 37. Better able to embrace and support unexpected work items</li></ul>Negatives<br /><ul><li>Greater discipline is required in ensuring that all tasks are completed in a timely manner</li></li></ul><li>Lessons Learned<br />Protect yourself. If you make the team better able to take on ad-hoc tasks, you must track the impact and the load. <br />I have found the following categorisations to be effective<br /><ul><li>Planned Product Development work
  38. 38. Planned Engineering work e.g. large scale refactoring
  39. 39. Unplanned Product work e.g. one of reports, small tweaks to behaviour
  40. 40. Unplanned engineering work e.g. urgent bug fixes </li></li></ul><li>Lessons Learned<br />Further observations<br /><ul><li>Adoption was almost completely painless
  41. 41. Due to day to day interaction, the board takes on a much more important role than it ever did under scrum
  42. 42. The team is more confident in deciding what to do next
  43. 43. Our stand ups have become much more focused
  44. 44. Our retrospectives are no longer coupled to the period of our iteration.</li></li></ul><li>Is Kanban for you?<br />You may find value in Kanban over Scrum if:-<br />The team has support, maintenance or Dev Ops responsibilities<br />Time boxed iterations make little sense in your work flow<br />Your priorities change rapidly<br />Your organisation is unable to easily support Scrum roles<br />You may also want to consider hybrid approaches such as ‘Scrumban’<br />
  45. 45. ScrumKanbanLessons Learned<br />
  46. 46. Wrapping up<br />Scrum provided us with structure and discipline<br />Kanban provided a better model for our work flow by embracing the unexpected and doing away with iterations<br />Limiting work in progress makes it easier to consider team level task prioritisation<br />Ad-hoc work stacks up, categorise all work items<br />Kanban is a tool, as is Scrum.Use the right tool for the job.<br />
  47. 47. And Finally…..<br />Contact<br /><ul><li>
  48. 48.
  49. 49. @neilisfragile</li></ul>References<br /><ul><li>
  50. 50.</li>