I apologize for the intentionally provocative title, but it is a bit of a counterreaction to the frequent questions “What is the difference between Scrum and Kanban?” or “Which one is better?” – questions which in my opinion do not make a lot of sense, so I am more and more tempted to give a provocative answer (which I will still try to partially justify below).
I feel that Scrum and Kanban are like “eating Italian food” and “eating with chopsticks”. Both eating Italian food and eating with chopsticks achieves the same purpose: the ingestion of food. The end result of both approaches is that you have eaten food. Still, both approaches are conceptually so different that nobody would ask “What is the difference between eating Italian food and eating with chopsticks” or “Which one is better?” And even though it is not common, it is possible to combine both approaches – you can certainly eat Italian food with chopsticks. In some cases, it might be counterproductive, in other cases, you will not gain anything from it, but in some cases, it might even be better than the “traditional” approach.
In the same way, it is probably pointless to compare Scrum and Kanban. While the end result of both is working software, both are conceptually so different that a 1:1 comparison does not make sense. And you can obviously even combine both – which in some cases might be counterproductive, in some cases pointless and in some cases great.
Still, the question “What is the difference” will still keep coming up, so it is worth coming up with a concise meaningful answer (outside of giving fully-day Scrum and Kanban classes).
This takes me back to the provocative headline though. I find the idea of viewing Scrum as a “type” of Kanban quite intriguing. Obviously, every Kanban or Scrum coach would (and should) object immediately to the idea that Scrum is a variant of Kanban. After all, it seems that both have only very superficial or general commonalities. Obviously, both foster self-organization and force the teams to visualize their work. But what about limiting the work in process (WIP) and managing the flow of tasks? These are core concepts of Kanban but not of Scrum. At least you will not hear anything about limiting the WIP in a pure Scrum training.
But that is the interesting part: Scrum DOES limit the WIP. It just happens more implicitly. In Kanban, it is done explicitly, e.g. by writing WIP limits above the task board. Kanban teams should talk about their WIP limits frequently and tune them. That is not a common explicit topic in Scrum retrospectives. Still Scrum limits the WIP implicitly. The WIP in Scrum is limited by the number of story points the team is willing or able to accept into a Sprint. And the goals in Scrum are similar to the goals of the limited WIP in Kanban: Do not build up a large “inventory” of in-work tasks and do not allow analysed, implemented or tested tasks to “decay” in their respective states. Give the customer quick results and solicit feedback as early as possible to avoid going down a wrong path for too long.
Both Scrum and Kanban limit the WIP and try to get tasks through the workflow to the “Done” column of the taskboard – Kanban by focussing on pulling tasks through the flow aggressively and Scrum by giving the team a goal at the end of the Sprint.
But this is also where the similarities end and where the “Scrum as a Kanban variant” idea breaks down. Kanban does much more than limit the WIP. Kanban is strongly focussed on getting tasks into Done – not at the end of an iteration, but as soon as possible. Scrum does not have the same intense focus on finishing work immediately but instead asks the team to finish the work by the end of the Sprint.
Also, as I mentioned before, in Scrum, the team usually does not make it a constant top priority to discuss the WIP and how it affects the flow of the work. The WIP is usually not being tuned frequently, but the team examines other aspects of the work to find ways for improving the performance.
So which value does this kind of a provocative statement have? Well, I believe that it is an interesting starting point for facilitating a discussion about how Kanban and Scrum are different on a conceptual level while still pursuing many of the same basic goals.
Also, the Sprint length is a frequent discussion point for Scrum teams. The development teams frequently try to push for longer Sprints for various reasons. There are various ways to try convincing the teams of how shorters Sprints are valuable, but perhaps an additional approach would be to view the Sprints not as “mini projects” with the goal of producing shippable increments, but as WIP limiters. It could be useful to look at the way how shorter Sprints affect the flow of the tasks, while discussing a concept like lead time and its impact. This might actually give one of the most common discussions in introducing Scrum a fresh perspective.
AgileEvangelist 