Case study of a Scrum team adopting 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.

24. 24
New challenges.

25. 25
Maintenance of production system.

26. 26
New team members.

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/