Or “When Should We Use Kanban Instead of Scrum?”

Or “When Should We Use Scrum Instead of Kanban?”

The two most popular Team practices are Scrum and Kanban. People often wonder whether one is better than the other, or whether one should be applied over another. This page will help you think through the ideas.

• Split your organization
  • Small, cross-functional, self-organizing teams
  • Split your work
  • Small, concrete deliverables
  • Assign someone to be responsible for the work item list and to sort the list by priority
  • Assign someone to be responsible for coaching and facilitating the team
  • Implementation team estimates the relative size of each work item
• Split time
  • Short fixed-length iterations (Usually 2 Weeks long, but Between 1 – 4 weeks)
  • Potentially shippable solutions demonstrated after each iteration
• Optimize the release plan
  • Update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration
• Optimize the process
  • Retrospective after each iteration

• Visualize the workflow
  • Split the work into pieces, write each item on a card and put on the wall
  • Use named columns to illustrate where each item is in the workflow
• Limit WIP (work in progress)
  • Assign explicit limits to how many items may be in progress at each workflow state
• Measure the lead time
  • Lead Time (sometimes called “cycle time”) = average time to complete one item
  • Optimize the process to make lead time as small and predictable as possible

• Both are Lean and Agile
• Both use pull scheduling
• Both limit Work-in-progress (WIP)
• Both use transparency to drive process improvement
• Both focus on delivering releasable solutions early and often
• Both are based on self-organizing (stable) teams
• Both require breaking the work into pieces
• Both optimize the release plan continuously based on empirical data

A notes on this criterion. Many teams whose work is the result of a ticketing system assume that all their work is demand driven, and that Kanban is therefore their only option. This is a problem in that if the team can plan work, they usually are also able to deliver better and faster over time.

Experience has shown that work coming from the ticketing system does not mean that we must treat every work item as interrupt-driven and therefore you are unable to plan it. For example, teams that are pure production support have different classes of incoming problems and so can vary how quickly you would need to respond to that problem. A production site is down request is going to need a more urgent response than say a minor defect because of a workflow problem. This gives as an option to plan more items and would mean that Scrum practices are useful. For example, if we can suggest to the customer “that they wait for (on average for a 2 week Iteration) 1 week for us to work this defect” then we can treat this as an input into the next planned Sprint (iteration) in a Scrum implementation.

In some instances up to 65% of the incoming work for a Team can be treated this way.

Which brings us to …

In some ways the discussion about whether you use EITHER Scrum OR Kanban is misleading. Like all agile approaches the best idea is to leverage Kanban and Scrum to improve how you deliver value. Scrum teams can benefit from ideas like understanding the workflow, WIP limits, classes of service. Kanban teams benefit from an understanding of the purpose of Scrum events, roles, and artifacts and incorporate some or all of them into their practice.

Here are some more specific approaches people have tried:

• Team Examples
  • Kanban Teams are set up as cross-functional
  • Scrum Teams set WIP Limits within a Sprint
  • Kanban Teams Setup cadence of retrospectives, daily meetings, etc
  • Scrum Teams establish (capacity-based) rules for Break-fix or other “interruptions”
• Team-of-Teams (Scaling) Examples
  • Kanban Teams commit to work on Sprint Schedule to aid in synchronization and Alignment
  • Portfolio and Program level work is set up as Kanban
• Retrospectives drive improvement
  • Scrum and Kanban as a toolbox of ideas to Leverage
  • Use whatever helps you improve

• "Kanban vs Scrum" by Henrik Kniberg - The source of a lot of the ideas in the presentation. As always, Henrik is brilliant.
• Scrum and XP from the Trenches by Henrik Kniberg
• Kanban Flow and Cadence by Karl Scotland
• Comparison of Kanban and Scrum. I have seen this type of deck in other places, but cannot find it easily so I’ve created something that can be used to help people understand. This page is the “Wiki-fied” version of this content.