From Scrum to Kanban




   Joakim Sundén
                       1
Joakim Sundén
• Agile/Lean/Kanban Coach at Avega Group
• Developer background
• David J. Andersons personal
  recommendati...
Kul
bild
här
       3
4

Scrum team with 6-7 developers, 2 testers, 1 architect, 1 requirements analyst and 1
ScrumMaster.
Three weeks sprints.
5

Retrospectives. Inspect and adapt.
We need longer
          sprints...




        Slack between
       sprint demo and
        sprint planning




         ...
More note-
    taking during Sprint
         planning




            No time to
        discuss stories and
          req...
Continuous
      delivery, deliver part of
              stories




      Finish stories before
     moving on to new one...
How do we demo
        integrations stories?




       I thought that was
     going to be fixed in the
          ‘next sp...
10

Already lean ingredients and philosophy in team.
http://leansoftwareengineering.com/
                                                                                      ...
The Kanban Expert
                                      ...and David J.
                                         Anderson
...
13

We simply called our approach “Flow”. One of the principles of lean.
We need longer
          sprints...

                                                        Just-in-Time planning!



   ...
More note-
    taking during Sprint
         planning




                                                      Just-in-Ti...
Continuous
      delivery, deliver part of
              stories
                                                         ...
How do we demo
       integrations stories?

                                                        Decouple demo/
      ...
18

Backlog-Development-Test-Fix. Ongoing-Ready.
Team added “Prepare” and “Good-to-go” later.
Started with with limit of 2...
19

Real board.
20

Story in development broken down to tasks. WIP limit on tasks indicated, but not 100%
enforced, by cat and dog avatars...
21

Legend for avatars. Later changed to more immediately recognizable Southpark avatars.
New Scrum Board
             worked well
                                                     More obvious what
          ...
23

Release! Paying off technical debt “outside of process” in post release hiatus.
24

New challenges.
25

Maintenance of production system.
26

New team members.
27

Team split in two. [Animation of cell splitting into two cells]
We don’t
      understand story
          points                                            T-shirt sizes and
            ...
29

At this time my engagement with the client came to an end.
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 ...
How can
    maintenance be part
       of the team?
                                 Classes of Service!




      How can...
32

Questions? E-mail joakim dot sunden at avega dot se. http://www.joakimsunden.com/
Upcoming SlideShare
Loading in …5
×

From Scrum To Kanban

3,423 views

Published on

Case study of a Scrum team adopting Kanban.

0 Comments
14 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,423
On SlideShare
0
From Embeds
0
Number of Embeds
284
Actions
Shares
0
Downloads
0
Comments
0
Likes
14
Embeds 0
No embeds

No notes for slide
  • 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/
  • From Scrum To Kanban

    1. 1. From Scrum to Kanban Joakim Sundén 1
    2. 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. 3. Kul bild här 3
    4. 4. 4 Scrum team with 6-7 developers, 2 testers, 1 architect, 1 requirements analyst and 1 ScrumMaster. Three weeks sprints.
    5. 5. 5 Retrospectives. Inspect and adapt.
    6. 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. 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. 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. 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. 10 Already lean ingredients and philosophy in team.
    11. 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. 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. 13 We simply called our approach “Flow”. One of the principles of lean.
    14. 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. 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. 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. 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. 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. 19 Real board.
    20. 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. 21 Legend for avatars. Later changed to more immediately recognizable Southpark avatars.
    22. 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. 23 Release! Paying off technical debt “outside of process” in post release hiatus.
    24. 24. 24 New challenges.
    25. 25. 25 Maintenance of production system.
    26. 26. 26 New team members.
    27. 27. 27 Team split in two. [Animation of cell splitting into two cells]
    28. 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. 29 At this time my engagement with the client came to an end.
    30. 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. 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. 32 Questions? E-mail joakim dot sunden at avega dot se. http://www.joakimsunden.com/

    ×