From Scrum To Kanban
•
16 likes•2,105 views
- The team transitioned from Scrum to a Kanban system with no iterations to address issues like lack of continuous delivery and pressure to complete all work by the end of each sprint. - They implemented Kanban practices like limiting work in progress, just-in-time planning, and decoupling demos from sprints. This improved focus and flow of work. - Over time, new challenges emerged as the team grew and split into two teams, and business stakeholders had different preferences around estimating work. The engagement ended as the teams refined their Kanban approach to maintenance further.
More Related Content
What's hot
What's hot (20)
Similar to From Scrum To Kanban
Similar to From Scrum To Kanban (20)
Recently uploaded
Recently uploaded (20)
From Scrum To Kanban
- 1. From Scrum to Kanban Joakim Sundén 1
- 2. Joakim Sundén • Agile/Lean/Kanban Coach at Avega Group • Developer background • David J. Andersons personal recommendation and endorsement as “knowledgeable Kanban coach” • http://www.joakimsunden.com/ 2
- 3. Kul bild här 3
- 4. 4 Scrum team with 6-7 developers, 2 testers, 1 architect, 1 requirements analyst and 1 ScrumMaster. Three weeks sprints.
- 5. 5 Retrospectives. Inspect and adapt.
- 6. We need longer sprints... Slack between sprint demo and sprint planning 6 Too much time disappears when everything stops for a day or two and then starts again. Pressure to deliver to review/demo.
- 7. More note- taking during Sprint planning No time to discuss stories and requirements 7 Developers don’t remember requirements discussed in beginning of sprint. Pressure to deliver and not immediately available Product Owner and analyst in mid-sprint.
- 8. Continuous delivery, deliver part of stories Finish stories before moving on to new ones We have to get better at working together on user stories 8 Working on too many stories at the same time, not delivering to test and review machine until late in sprint.
- 9. How do we demo integrations stories? I thought that was going to be fixed in the ‘next sprint’ 9 Sometimes the stories in a sprint aren’t that interesting to busy off-site stakeholders. Incremental delivery of features broken down to small stories makes stakeholders pay less attention to problems (“probably delivered in the next sprint”).
- 10. 10 Already lean ingredients and philosophy in team.
- 11. http://leansoftwareengineering.com/ 11 Read some of Corey Ladas blog posts. There was talk about “no iterations” at an Agile Sweden conference, but no connection to Kanban.
- 12. The Kanban Expert ...and David J. Anderson 12 No close acquaintance with David J. Anderson and his work with Kanban as a method yet - that was to come later.
- 13. 13 We simply called our approach “Flow”. One of the principles of lean.
- 14. We need longer sprints... Just-in-Time planning! Slack between sprint demo and sprint planning Limit work to capacity! 14 Plan stories when needed. Eliminated negative slack and “stop & go”. Work was pulled and limited to capacity rather than pushed. Pressure to deliver would not go away easily though...
- 15. More note- taking during Sprint planning Just-in-Time planning! No time to discuss stories and requirements 15 Just-in-Time planning also helped keep the discussion between developers and Product Owner and analysts fresh and on-going.
- 16. Continuous delivery, deliver part of stories Limit work in progress! Finish stories before moving on to new ones Planning work, We have to get Story Captain! better at working together on user stories 16 WIP limits formally prescribed cooperation when working with stories. Story Captain was responsible for planning work on the story so that it was easy for others to help finish the story when they had capacity.
- 17. How do we demo integrations stories? Decouple demo/ review from sprint! I thought that was going to be fixed in the ‘next sprint’ 17 Review/demo only when it made sense to Product Owner and stakeholders. Typically about every 3 to 5 weeks.
- 18. 18 Backlog-Development-Test-Fix. Ongoing-Ready. Team added “Prepare” and “Good-to-go” later. Started with with limit of 2 stories for development (made physical on board). 7-8 developer found this a bit hard at times, increased to 3 after a few weeks. WIP limit increased further and dropped completely when new developers joined team, ScrumMaster role became unclear and there was a lot of pressure to deliver the first big release.
- 19. 19 Real board.
- 20. 20 Story in development broken down to tasks. WIP limit on tasks indicated, but not 100% enforced, by cat and dog avatars. Warning signs in yellow (risk of not delivering in estimated time) and red (won’t deliver in time).
- 21. 21 Legend for avatars. Later changed to more immediately recognizable Southpark avatars.
- 22. New Scrum Board worked well More obvious what people are working with Our work was focused and goal-oriented Limiting parallel work to two stories was good 22 The result? Team was happy with changes. Soon “release chaos” ensued and discipline with process disappeared as team focused a lot on delivering in time.
- 23. 23 Release! Paying off technical debt “outside of process” in post release hiatus.
- 25. 25 Maintenance of production system.
- 27. 27 Team split in two. [Animation of cell splitting into two cells]
- 28. We don’t understand story points T-shirt sizes and lead times! Smaller stories! Bigger stories! MMFs and stories! 28 Business side did not understand story points and wanted to communicate in days and hours. Team settled on t-shirt sizes and date stamps on story for the different steps in the workflow in order to calculate lead time. Developers wanted small stories, business wanted features. Separate ideation board for Product Owner and analyst with something similar to MMFs was proposed. Broken down into stories in a dev step. Teams Kanban boards to be seen as expansions of this step.
- 29. 29 At this time my engagement with the client came to an end.
- 30. 30 Board for one of the teams at the start of next phase just before I left. Removed “fix” column and let defects go into dev queue instead. Happy stories (rightmost col), technical stories that makes devs happier when solved, to work with when idle increases understanding of less capacity utilization when limiting WIP.
- 31. How can maintenance be part of the team? Classes of Service! How can Product Owner and Requirements Analyst work with two teams and Kanban? Ideation board, shared backlog! 31 Plans for the future...
- 32. 32 Questions? E-mail joakim dot sunden at avega dot se. http://www.joakimsunden.com/
Editor's Notes
- Scrum team with 6-7 developers, 2 testers, 1 architect, 1 requirements analyst and 1 ScrumMaster. Three weeks sprints.
- Retrospectives. Inspect and adapt.
- Too much time disappears when everything stops for a day or two and then starts again. Pressure to deliver to review/demo.
- Too much time disappears when everything stops for a day or two and then starts again. Pressure to deliver to review/demo.
- Developers don’t remember requirements discussed in beginning of sprint. Pressure to deliver and not immediately available Product Owner and analyst in mid-sprint.
- Developers don’t remember requirements discussed in beginning of sprint. Pressure to deliver and not immediately available Product Owner and analyst in mid-sprint.
- Working on too many stories at the same time, not delivering to test and review machine until late in sprint.
- Working on too many stories at the same time, not delivering to test and review machine until late in sprint.
- Working on too many stories at the same time, not delivering to test and review machine until late in sprint.
- Sometimes the stories in a sprint aren’t that interesting to busy off-site stakeholders. Incremental delivery of features broken down to small stories makes stakeholders pay less attention to problems (“probably delivered in the next sprint”).
- Sometimes the stories in a sprint aren’t that interesting to busy off-site stakeholders. Incremental delivery of features broken down to small stories makes stakeholders pay less attention to problems (“probably delivered in the next sprint”).
- Already lean ingredients and philosophy in team.
- Read some of Corey Ladas blog posts. There was talk about “no iterations” at an Agile Sweden conference, but no connection to Kanban.
- No close acquaintance with David J. Anderson and his work with Kanban as a method yet - that was to come later.
- We simply called our approach “Flow”. One of the principles of lean.
- Plan stories when needed. Eliminated negative slack and “stop & go”. Work was pulled and limited to capacity rather than pushed. Pressure to deliver would not go away easily though...
- Plan stories when needed. Eliminated negative slack and “stop & go”. Work was pulled and limited to capacity rather than pushed. Pressure to deliver would not go away easily though...
- Just-in-Time planning also helped keep the discussion between developers and Product Owner and analysts fresh and on-going.
- WIP limits formally prescribed cooperation when working with stories. Story Captain was responsible for planning work on the story so that it was easy for others to help finish the story when they had capacity.
- WIP limits formally prescribed cooperation when working with stories. Story Captain was responsible for planning work on the story so that it was easy for others to help finish the story when they had capacity.
- Review/demo only when it made sense to Product Owner and stakeholders. Typically about every 3 to 5 weeks.
- Backlog-Development-Test-Fix. Ongoing-Ready. Team added “Prepare” and “Good-to-go” later. Started with with limit of 2 stories for development (made physical on board). 7-8 developer found this a bit hard at times, increased to 3 after a few weeks. WIP limit increased further and dropped completely when new developers joined team, ScrumMaster role became unclear and there was a lot of pressure to deliver the first big release.
- Backlog-Development-Test-Fix. Ongoing-Ready. Team added “Prepare” and “Good-to-go” later. Started with with limit of 2 stories for development (made physical on board). 7-8 developer found this a bit hard at times, increased to 3 after a few weeks. WIP limit increased further and dropped completely when new developers joined team, ScrumMaster role became unclear and there was a lot of pressure to deliver the first big release.
- Real board.
- Story in development broken down to tasks. WIP limit on tasks indicated, but not 100% enforced, by cat and dog avatars. Warning signs in yellow (risk of not delivering in estimated time) and red (won’t deliver in time).
- Legend for avatars. Later changed to more immediately recognizable Southpark avatars.
- The result? Team was happy with changes. Soon “release chaos” ensued and discipline with process disappeared as team focused a lot on delivering in time.
- The result? Team was happy with changes. Soon “release chaos” ensued and discipline with process disappeared as team focused a lot on delivering in time.
- The result? Team was happy with changes. Soon “release chaos” ensued and discipline with process disappeared as team focused a lot on delivering in time.
- The result? Team was happy with changes. Soon “release chaos” ensued and discipline with process disappeared as team focused a lot on delivering in time.
- Release! Paying off technical debt “outside of process” in post release hiatus.
- New challenges.
- Maintenance of production system.
- New team members.
- Team split in two. [Animation of cell splitting into two cells]
- Business side did not understand story points and wanted to communicate in days and hours. Team settled on t-shirt sizes and date stamps on story for the different steps in the workflow in order to calculate lead time. Developers wanted small stories, business wanted features. Separate ideation board for Product Owner and analyst with something similar to MMFs was proposed. Broken down into stories in a dev step. Teams Kanban boards to be seen as expansions of this step.
- Business side did not understand story points and wanted to communicate in days and hours. Team settled on t-shirt sizes and date stamps on story for the different steps in the workflow in order to calculate lead time. Developers wanted small stories, business wanted features. Separate ideation board for Product Owner and analyst with something similar to MMFs was proposed. Broken down into stories in a dev step. Teams Kanban boards to be seen as expansions of this step.
- Business side did not understand story points and wanted to communicate in days and hours. Team settled on t-shirt sizes and date stamps on story for the different steps in the workflow in order to calculate lead time. Developers wanted small stories, business wanted features. Separate ideation board for Product Owner and analyst with something similar to MMFs was proposed. Broken down into stories in a dev step. Teams Kanban boards to be seen as expansions of this step.
- Business side did not understand story points and wanted to communicate in days and hours. Team settled on t-shirt sizes and date stamps on story for the different steps in the workflow in order to calculate lead time. Developers wanted small stories, business wanted features. Separate ideation board for Product Owner and analyst with something similar to MMFs was proposed. Broken down into stories in a dev step. Teams Kanban boards to be seen as expansions of this step.
- Business side did not understand story points and wanted to communicate in days and hours. Team settled on t-shirt sizes and date stamps on story for the different steps in the workflow in order to calculate lead time. Developers wanted small stories, business wanted features. Separate ideation board for Product Owner and analyst with something similar to MMFs was proposed. Broken down into stories in a dev step. Teams Kanban boards to be seen as expansions of this step.
- At this time my engagement with the client came to an end.
- Board for one of the teams at the start of next phase just before I left. Removed “fix” column and let defects go into dev queue instead. Happy stories (rightmost col), technical stories that makes devs happier when solved, to work with when idle increases understanding of less capacity utilization when limiting WIP.
- Plans for the future...
- Plans for the future...
- Plans for the future...
- Plans for the future...
- Questions? E-mail joakim dot sunden at avega dot se. http://www.joakimsunden.com/