Kanban is promoted by several people as being the new thing that will replace Scrum as the favored Agile way of working. So people ask: “should we go Kanban instead of Scrum?”

Well, should we have a hamburger or listen to Mozart? In my view Kanban and Scrum are two different ideas that do not operate in the same areas of business.

1. Kanban deals with optimizing a steady flow production like tasks, inherently an operational approach. Very useful for unplanned tasks or for a continuous stream of work with  a very simple level of complexity.
2. Scrum deals with setting boundaries for new product development with high complexity. That means for things in which we do not know how to perform the tasks. Scrum defines and executes the necessary planning aspects of product development and creates a frame that guides teams to actual perform the work.

To me Scrum is the big picture of how we generate value out of effort in organizations. We can use Kanban inside Scrum Sprints as a way of executing the work.

If Kanban is used on its own, and there may be lots of work scenarios, where that is appropriate, I think of Kanban as Scrum where the Sprint is reduced to one day or perhaps completely abandoned.

People who advocate Kanban over Scrum often hail the fact that there are not the same restrictions and rules, you don’t have to do Sprints, you don’t have to do Estimation, you don’t have to do Retrospectives. I wonder, are we seeing the old dislike of organization or boundaries in development groups rearing its head again? We want to do what we see best fit, when we want it.

The absence of boundaries is not in itself a positive, we are not in Height Ashbury in 67, the summer of love, any more. Boundaries are absolutely necessary if we do want to establish self-organization. In order to establish common understanding about the product, we need to have a common language, a clear vision, a guideline in what direction we are heading and and and. You can compare Scrum rules with the traffic-law. These boundaries establish a framework for getting from A to B and surviving the process.

I will try to elaborate a bit on this.

So what is Scrum really?

Scrum is a philosophy, a way of thinking about and attacking projects and campaigns of a certain size and complexity in such a way that near-optimal outcome is achieved.

The heart of the Scrum philosophy is the “Spirit of constant improvement:”

1. At the  strategic level it is about finding the value and cost of deliverables (Product Backlog Items - PBIs), and prioritizing the smartest deliverables to deliver next.
2. At the tactical level it is about how to set up a mission of deliverables that can be designed and broken down into tasks.
3. At the task level (sometimes referred to as operational) it is about deploying factual skills to accomplish tasks and securing these are executed in order to complete a deliverable.

Overarching this is the fundamental philosophy of making impediments and obstacles visible and dealing with them in real time to keep momentum and commitment up.

A set of boundaries is implemented in Scrum to facilitate the goals mentioned above:

1. We have a defined “modus operandi”: Work is split into short Sprints with frequent delivery of finished deliverables.
2. We have defined roles with responsibilities: Product Owner, Scrum Master and Team.
3. We have defined meetings: Sprint Planning (1,2 and now Estimation), Daily Scrum, Sprint Review and Retrospective.
4. We have defined artifacts: Product Backlog with deliverables, Sprint Backlog (task board) with deliverables broken down into tasks and an Impediment Backlog.

And what is Kanban then?

Kanban is essentially an advanced taskboard, typically with different stages (states) that work in progress (WIP) have to pass through to be completed, the workers (team) pull from upstream stages. At each stage a limit of deliverables allowed in this stage is imposed to minimize the amount of WIP and create a harmonic flow to reduce lead time.

That’s it! Regarding the rest of everyday structure you are on you own.

The argued benefits of Kanban over Scrum

Let us now look into the different practices of both approaches in order to see the benefits of the both ideas from the viewpoint of Kanban.

1. Limiting work in progress

Often the primary benefit of Kanban is supposed to be an explicit limiting of work in progress (WIP).

That is however inherent in Scrum, where we focus on getting deliverables to “Done” as quickly as possible. By breaking the tasks needed for a “Done” deliverable down into pieces that normally only takes about one day to complete it is easily discovered and dealt with. It is true that there is no explicit limit on WIP given in Scrum, although advocates of Scrum tell people to minimize WIP.

In gerneral that is fully compliant to the idea of Scrum, as it is assumed that the Team have enough overview of the work in the Sprint to be able manage that complexity without waste. The split of work into Sprints reduces the local complexity in the Sprint, so this is normally not an issue.

In fact the explicit limiting of WIP in Kanban creates an unnecessary pressure on people. Instead of giving people a guideline how to do their work, the process of Kanban forces them to work in a specific way.

2. Reflecting the different stages of work in progress

In Kanban it is typical to have WIP split into for example stages of “Design”, “Implementation”, “Test” and more.

On one side, this can be helpful, and Scrum does really not say anything about how the Task board or Sprint Backlog should look. All we say is that the Sprint Backlog must exist in order to follow progress and enable quick intervention if something goes haywire.

On the other side this impacts the self-organization capabilitiies of a cross functional team. Defining these stages does not encourage people to take on tasks they are not used to do and reinforces old habits of specialized roles. It encouraged people to stick to what they know.

3. The absence of rules

It is argued that since Kanban only states very little everybody is free to develop the structures they need. Everybody should use the tools they find useful.

Looks great! But is not true. Creativity needs boundaries. Teams needs boundaries. Scrum is an empirically proven starting point, and one that everybody can understand. Total liberty is not a blessing, but a curse. By starting with a well defined framework (which Scrum is) everybody hits the ground running and the rest of the organization can understand this “project language” it is not freshly invented every time.

As teams and organizations mature, sure they will make local adaptations and adjustments to the Scrum of the books, but that is not the same as dropping all boundaries.

Consequences of adapting just Kanban

My opinion is, that if you just do Kanban you confine your area of leadership impact to the pure tactical and task oriented level. All strategical and team concerns are not dealt with - or you have to invent some extra things on top of Kanban to cover that.

Kanban is production, well suited to a constant stream of work, where each stage of work is fairly well defined.  Some examples may help:

1. Kanban has no roles. Scrums primary success-driver is that all the players have well defined responsibilities and matching authority. It is my belief that improvement in Scrum comes primarily from each of the three core roles being extremely focused on their job and being sure of what is expected from them. That is gone with pure Kanban.
2. Kanban has no Sprints, it is a continuous flow. In Scrum we make a localised simple project Sprint after Sprint, the whole project may be ugly and complex, but for the next two to four weeks, we know exactly what is expected of us and what to do, it is a simple mini-project. That gives the Team peace of mind and freedom to be creative within the boundaries, and it gives the rest of the organization a committed expectation about what will be delivered in the next Sprint. That is gone with pure Kanban.
3. Kanban has no estimation. Estimation as the first stage in a continous strive for a common understanding is the foundation for the Team to be able to commit to deliverables in a Sprint. Estimation is also the basis on which the Product Owner does his release planning and aligns the project with the rest of the organization, meeting deadlines etc. Estimates are also valuable for the Product Owner when he prioritizes deliverables, if he discovers that a certain deliverable is very costly to obtain, he may think twice before commissioning it. In pure Kanban how would you ever get to budget for given set of deliverables?
4. Kanban has no Daily Scrum Meeting. And you do not need one any more as people do work in silos. Testers test, developers develop. Well no, Kanban has no Sprint so the only thing there would be to do on a daily meeting would be to discover impediments.
5. Kanban has no Retrospective meeting. Unless otherwise catered for, this ruins the constant improvement cycle, the Retrospecitve is where facts are discovered are reflected upon, larger impediments are brought out in the open and areas of improvement identified. That is gone with pure Kanban.
6. Kanban has no Impediment Backlog. It is often mentioned that one of the things that really improves people’s commitment and also well-being on the job is the fact that impediments and obstacles are dealt with in real-time (by the Scrum Master in Scrum). People experience that their work is important enough for someone (the Scrum Master) to bother to remove whatever prevents their work, this prevents frustrations. That is gone with pure Kanban.

Conclusion

Kanban on its own is suited for a constant stream of jobs to do, for example as in production, operations or support departments. In such work the notion of a Sprint is often not possible, people may not know in advance what will hit them. Often there is also no discussion about business value or estimate of a certain job or deliverable, it just has to be done. If the main server is down, just get it up again.

Scrum on the other hand is about strategically choosing what to do with the resources available. It is a way of running an organization with constant demand to invent or change.

My claim is that Kanban and Scrum deal with two different realms. Kanban is about firefighting, Scrum is about lighting fires (the right ones of course).

Kanban is a defensive “modus operandi”, Scrum is an offensive one.

2010-07-18. Certified Scrum Trainer, Kurt B. Nielsen