Key differences between Scrum and Kanban

Difference between Scrum and Kanban

Here we jump a bit deeper into the core thinking of Scrum and Kanban.

Key differences between Scrum and Kanban

  • Kanban’s focus is to minimize cycle time (the total expended time on an item of work). This is a really important point.  It does not track “points” and “velocity” per se.  Once a team or sub-team starts something, they should focus on completing it.  (This is most efficient.)
  • Both use workboards, but Kanban outlines the process in more detail, AND Kanban has To-Do, In-Progress, and Done for each step in the process!  Why?
  • Kanban identifies bottlenecks in the process.  You can see this visually on the board because work-in-process (WIP) will pile up in To-Do at the bottleneck step.
  • Kanban has a culture of “slack resources” helping the bottleneck when needed.  Slack resources are any non-bottleneck resource.  This is very interesting.  So if there’s a backlog in testing, any available resource should help test to complete the task (cycle-time minimization) before taking on more work (WIP limit).
  • Kanban has WIP limits for each step in the process. A new task is not started until a “slot” opens up.
  • Kanban does not have Sprints, nor does it try to fit work into time-boxes.  Rather its an ongoing process.  As mentioned above, new work items are added only when available slots become open, not in a time-boxed manner as with Scrum and Sprints.

Although there are more differences, I think these are the main points.

What does this mean for most teams?

  • If your process is often interrupted and “ticket-based”, Kanban may be a good fit. Kanban is popular among Operational teams.  The unreliance on sprint boundaries and the focus on minimizing cycle time (getting the work resolved and through the system quickly) fit very well with ticket-based processes.
  • Kanban is really great at exposing bottlenecks within your value stream.  This is very helpful for optimizing your process and throughput.  Kanban’s cultural focus of everyone helping the bottleneck if needed is interesting to see.  For example, developers helping testers test is out of the norm for many developers.

What I like:

  • I like both. Both offer great tools and techniques for visualizing and optimizing the flow of work. If you feel you have the basic stuff mastered then feel free to mix it up with Scrumban, a variation of Scrum and Kanban.
  • I like the lightweight process surrounding Kanban.  The WIP limits and “available slot” mental models really drive efficiency.  The reality is, people can really only work on one thing at a time, so limiting the number of things in someone’s queue makes a lot of sense.  Adding more, and increasing task switching, has proven to be the biggest money burner in large enterprises.
  • The cadence and compulsory checkpoints in Scrum makes it a safe framework to start the journey.  Rythm and the ability to plan with the help of velocity really helps building some confidence with newer teams. I like to think of the process checkpoints inherent in Scrum as training wheels. Once the behavior becomes second nature we remove them and ensure the new status quo remain.

What’s Next?

  • Please share your thoughts with us either below or on Social media (buttons on page).
  • Get a free mini book on Kanban and Scrum – Making the Most of Both. You can download it from here.
  • Subscribe to our Newsletter here for savings on training and the latest industry thinking.
  • Peruse our Training Offering from the top menu. Our SAFe® Scrum Master and SAFe Advanced Scrum Master courses may be just what you need.

Please follow and like us:

Leave a Reply