Scrum provided structure and discipline but the team found it inflexible for their needs. They switched to Kanban which allowed greater flexibility while still providing transparency. Kanban uses work in progress limits instead of iterations and focuses on reducing lead time. The team found Kanban a better fit and observed benefits like being able to embrace unexpected work, while requiring more discipline to avoid work piling up. In summary, the team transitioned from Scrum to Kanban and found it improved their ability to handle varied work.

1. From Scrum to Kanban Neil Johnson

2. ScrumKanbanLessons Learned

3. “The only thing that really matters is the quality of the team. Everything else is an optimisation.“

4. ScrumKanban Lessons Learned

5. Working environment Software as a Service Services sold on their reliability and availability Industry is still very young, continual innovation is essential Teams are cross functional All members responsible for design, implementation, deployment and maintenance Easy access to Product Development/Business

7. White board and post its to track status

8. Daily stand ups

10. No formal product owner

12. Scrum was great but we had two problems with it….

13. The iteration deadline felt artificial No expectation from business of a post iteration demo High dependence on outside parties Frequently over/undershoot due to external dependencies Time box limited choice of tasks in case of undershoot

15. The team is responsible for 2nd line support, operations and maintenance

16. We can assign a maintainer role to shield the team from day to day requests, though this is not always sufficient

19. Both use pull scheduling

20. Both use transparency to drive process improvement

22. Kanban does not prescribe fixed iterations

23. In Kanban Lead Time is the principle metric, in Scrum it is velocity

26. Represent each work item on a post it and put on the board

28. A simple example

29. A more complicated example

30. The post its

31. How to measure lead time and optimise the process?

32. Cumulative Flow Diagram Aslak Hellesøy

33. Lead Time

34. ScrumKanban Lessons Learned

36. We no longer feel that we are fighting our process

38. Planned Engineering work e.g. large scale refactoring

39. Unplanned Product work e.g. one of reports, small tweaks to behaviour

41. Due to day to day interaction, the board takes on a much more important role than it ever did under scrum

42. The team is more confident in deciding what to do next

43. Our stand ups have become much more focused

45. ScrumKanbanLessons Learned

46. Wrapping up Scrum provided us with structure and discipline Kanban provided a better model for our work flow by embracing the unexpected and doing away with iterations Limiting work in progress makes it easier to consider team level task prioritisation Ad-hoc work stacks up, categorise all work items Kanban is a tool, as is Scrum. Use the right tool for the job.

48. http://fragile.org.uk/

50. http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf