Moving from Scrum to Kanban


Published on

Talk I gave at Norwegian Development Conference in June 2012.

Many teams who are already using Scrum would like to know what benefits they can get by moving to Kanban. Dropping the Sprint timebox can seem quite scary but on the other hand spending less time planning and estimating seems attractive to many developers. How do you know that you haven't thrown the baby out with the bathwater?
Come to this talk to hear about what Kanban can bring your team and what practical steps you take to get started and keep going through the rough patches. We also take a look at potential pitfalls with Kanban and situations where you might want to move back to vanilla Scrum. I'll illustrate this talk with some stories from teams I've been coaching at BBC and Deutsche Bank.

Published in: Technology

Moving from Scrum to Kanban

  1. 1. Moving fromScrum to Kanban Rachel Davies @rachelCdavies Copyright 2012, Industrial Logic, Inc. All Rights Reserved.
  2. 2. My Background• Started applying as a developer XP in 2000• Became an agile coach and wrote a book• Practical person when it comes to approach
  3. 3. What I’ll be talking about• Many teams use Scrum• They have heard about Kanban• How do teams evaluate whether to try Kanban?• What are the basic steps to get started?
  4. 4. Scrum? Who is using Scrum?
  5. 5. Scrum: a framework fordeveloping and sustainingcomplex products
  6. 6. Sprint: a time-box of one month or less duringwhich a releasable product increment is created.
  7. 7. Scrum: a series of SprintsSprint 1 Sprint 2 Sprint 3 Product Product Product Increment 1 Increment 2 Increment 3 “Each Sprint may be considered a project with no more than a one-month horizon.” -- Scrum Guide
  8. 8. Why “Sprint”?Clear goal withdedicated team
  9. 9. Upside?
  10. 10. ★ The Sprint is a constraint that encourages collaboration★ Regular cycle allows stakeholders to know when they’re input is required
  11. 11. Downside?
  12. 12. Downside of Sprints• Cutting corners to meet the date• Unfinished work• Increment scoped to match timebox rather than needs
  13. 13. “Scrummerfall?”Requirements Sprint 1 Sprint .. Sprint .. Testing Sprints with no releasable Product Increments!
  14. 14. Burndowns
  15. 15. Whatdoes thistell you?
  16. 16. When do we doProduct BacklogGrooming?How much is enough?
  17. 17. 看板 What is Kanban ?Japanese word for visual signal card Who here is using Kanban?
  18. 18. Kanban for software development• “Lean is a destination; kanban is a means to get there.” -- David J. Anderson
  19. 19. VisualizeSeeing how workflows helps us getrocks out of the way.
  20. 20. Make Queues VisibleWait times for rides at Disney Park
  21. 21. Make current work visible?
  22. 22. And then ...?
  23. 23. Red, leather seats, ... Date order received, time work started, etc.Customer orders are pulled through Toyotaproduction line with Kanban cards.Kanban cards also used to control numberof parts available in the production line.
  24. 24. Inventory is WasteRequirements Tasks Started Ready Live Too much work in process and nothing released
  25. 25. Limit Work-in-ProcessRequirements In Progress Ready Live [3] [2] [1] Limiting WIP improves flow Pull rather than push
  26. 26. CumulativeFlow charts that help us visualize flow.
  27. 27. # items Seeing Work-in-Process Cycle Time WIP
  28. 28. # items Monthly Releases
  29. 29. # items Scrummerfall
  30. 30. Bottlenecks
  31. 31. “Any resource whosecapacity is less than thedemand placed on it”Eliyahu M. Goldratt
  32. 32. Buffers and Slack• Focus on flow rather than utilisation• Small buffers in the system mean people don’t run out of work
  33. 33. # items Waiting for test
  34. 34. Limit the WIPRequests Stories Dev Ready QA Ready Live [3] [5] [3] for QA [3] [1] [4] When you hit the limit PULL
  35. 35. How Do We Operate WIP Limits?• The limit governs the maximum number of work items that can be in that state at any instant.• If a state is below its limit then it may take possession of a work item from upstream.• If a state is at its limit, it must wait for one of its own items to be complete, and pulled downstream. -- David Joyce
  36. 36. # items Limited WIP
  37. 37. Getting Started with Kanban
  38. 38. Step 1 Team sketches end- to-end workflow• What states does work go through?• Where does it wait around?
  39. 39. Step 2 Initial Board Design What! No WIP limits?
  40. 40. Step 3 Daily Standup • Is the board correct? • Do we have a blocker not dealt with? • Do we have a bottleneck? look for congestion or gaps in the queues • Are we keeping to our WIP limits? • Are priorities clear?
  41. 41. Step 4 Decide on Limits • Lower limits reduce cycle times and increase flow of value • Very low limits cause work to stall • Allow for variability of work • Start with: limit = number of people x 1.5
  42. 42. Exceeding limits?
  43. 43. Step 5 Reflect on What You See Why was this bug so difficult to fix?
  44. 44. What about meetings and release frequency?
  45. 45. Decoupling fromSprint timeboxEvents have independent cadenceor can be triggered by a limit.
  46. 46. Is the team losing their way?
  47. 47. Back to Basics Scrum rules can set team up for success until they’re ready to ride out on their own.
  48. 48. Questions?rachel@industriallogic.comtwitter: rachelcdavies