In agile teams the use of both Scrum and Kanban is widespread. What is the difference between Scrum and Kanban? At what point does it make sense to use Kanban over Scrum?
This article helps you identify the limitations of Scrum and when it is time to break with the rules. It outlines how Kanban can be a natural evolution for Scrum teams.
Scrum and Kanban in a nutshell
I recently read the book Scrum and Kanban: Making the most of both. It is a short read and I can highly recommend it to get a quick overview on the topic. Here are the key facts for me:
Both are very similar and come with very few restrictions. That means most decisions are still up to the team. Both are lightweight frameworks and not a strict process to follow by the book.
Kanban is less constrained. It only has three simple rules:
- Visualise the workflow
- Limit work in progress (WIP)
- Measure & optimise lead time
Scrum on the other hand is slightly more prescriptive. It describes specific roles and has more artefacts:
- Iterations with fixed lengths called sprints and the sprint backlog
- Cross-functional, self-organising teams
- A product owner responsible for priorities and managing the product backlog
- A scrum master supporting the Scrum team
- Regular meetings such as daily stand-ups and retrospectives.
Scrum and Kanban both limit work in progress (WIP). Kanban usually does that per workflow state. Scrum limits WIP by limiting the sprint scope.
Limitations of Scrum
Scrum offers a great starting point for teams and organisations new to agile principles. The Scrum framework offers more guidance. However in the long run a team can outgrow Scrum and evolve into a Kanban team. Here are some concrete examples I have experienced myself:
Artifical release cycles
Fixed sprints are a great way to push a team to release continuously and in small chunks. If you only release your product every quarter or month, a release every 14 days is a massive improvement.
If you adhere to the mantra of continuous improvement your release cycles are ought to become shorter and shorter.
After a while of constant improvements you might already be releasing continuously throughout the sprint. At this point your sprint becomes an artificial cycle which does not add value. The Kanban perspective is more in line with reality: Work transitions through a flow, it does not happen in discrete chunks.
Unresponsive prioritisation
In Scrum you limit work in progress by limiting the sprint scope. That means your prioritisation cycle is at least 2 weeks (the typical sprint duration). Assuming that new information which changes your priorities can happen any day of the week you will on average wait for one week for your prioritisation changes to take effect.
In Kanban the team can pull the next story right after one finishes. That means your responsiveness to reprioritisation is essentially your cycle time – the time it takes on average from starting to finishing a story.
If your cycle time is smaller than one week a Kanban workflow is more agile
While the idea of a sprint is a great improvement coming from a waterfall process it can eventually become a limitation. If your cycle time is shorter than one week a Kanban workflow is simply more agile.
Once again the Kanban way of working describes more accurately what is really happening. This reduces friction between teams, customers and stakeholders.
Backlog of empty promises
In Scrum the product owner maintains a prioritised backlog. When a new sprint starts the team pulls work from the top of the backlog. Kanban is again less prescriptive here. You can simply have a Todo column at the beginning of your workflow, it does not even have to be prioritised.
For most teams there are more ideas and requests incoming than work to be done. So the backlog has the natural property to grow constantly. Without a very strict process of saying No and dropping stories from the backlog when new stories are added or reprioritised it is hard to stay on top of things. While this is a practical issue and at its core a failure of the product owner’s responsibilities it is all too common nevertheless. You can find an interesting discussion about that on Twitter with the #noBacklog hashtag.
The Kanban rule of WIP limits makes a striking difference here. The Todo column can and should be WIP limited. This keeps the lid on an otherwise ever growing backlog.
Roles meeting reality
Kanban does not prescribe explicit roles. In Scrum there is a Scrum Master and a Product Owner besides the development team. Especially when establishing a new team it is incredibly helpful to have someone to take care of sticking to a new process and supporting the team wherever possible. Likewise it is crucial that someone takes responsibility for the product and prioritisation.
Both of these roles can bring tremendous values to new teams. At a certain level of team maturity those benefits begin to taper off. The same roles can become bottlenecks or blockers to the growth of a team or product. I covered much of this problem in my series on collaborative product ownership.
Not relying on single roles is the next step to truly self-organising and empowered teams.
An evolution without shortcuts
Scrum brings a lot of value to a team which is used to top-down decision making and waterfall processes. Once a team has ingrained agile principles into all aspects of their daily work Scrum can be more limiting than enabling. At this point it makes sense to break out of the Scrum boundaries and adapt a more flexible tool – Kanban.
However, Kanbans flexibility has to be applied wisely. Since Kanban is more permissive than Scrum it’s easy to use Kanban and at the same time not be agile at all. That is why I see the transition from Scrum to Kanban an evolution: First you have to establish agile practices under a slightly stricter regimen. Only after those practices come naturally can you loosen the limitations and start establishing your own boundaries. Trying to take shortcuts on this agile evolution will probably backfire.