From Scrum To Kanban

From Scrum to Kanban Joakim Sundén 1

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

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 6 Too much time disappears when everything stops for a day or two and then starts again. Pressure to deliver to review/demo.

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.

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.

How do we demo integrations stories? I thought that was going to be ﬁxed 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 Already lean ingredients and philosophy in team.

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.

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 We simply called our approach “Flow”. One of the principles of lean.

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...

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.

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 ﬁnish the story when they had capacity.

How do we demo integrations stories? Decouple demo/ review from sprint! I thought that was going to be ﬁxed 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 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 ﬁrst big release.

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. Warning signs in yellow (risk of not delivering in estimated time) and red (won’t deliver in time).

21 Legend for avatars. Later changed to more immediately recognizable Southpark avatars.

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 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 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 workﬂow 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 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 “ﬁx” 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.

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 Questions? E-mail joakim dot sunden at avega dot se. http://www.joakimsunden.com/

http://www.joakimsunden.com	128
http://www.slideshare.net	29
http://joakimsunden.com	18
http://feeds.feedburner.com	11
http://www.lmodules.com	1
http://74.220.207.167	1

From Scrum To Kanban

by Joakim Sundén on Oct 23, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

6 Embeds 188

Statistics

From Scrum To Kanban — Presentation Transcript