Scrum is, like Kanban, a process framework, which applies the values and principles of Agile and Lean. In order to compare them, here is a one-minute description of Scrum.

In Scrum it is prescribed that you should have a cross-functional team, that is, a team with all competences needed to develop a whole feature. There should be a Scrum Master who is the master of the Scrum framework with the mission to make sure the team's process works well, is effective and is according to Scrum. There is also a Product Owner who knows the vision of the product, communicates with the stakeholders, and makes sure the team knows what is the right thing to be working on and in which priority.

The following diagram shows people involved in a scrum:

Scrum prescribes that you have a Product Owner who collects and prioritizes work to be done from the stakeholders.

In Scrum you work in iteration or Sprints of usually 1-4 weeks. Each Sprint starts with the planning of work for the Sprint and ends with a releasable increment of features. Hopefully the plan remains unchanged all through the Sprint.

Kanban has fewer rules. For instance, there is nothing about roles or about working in iterations. Kanban is more focused on continuous flow, visualizing the work and optimizing the time between ideas and runnable features.

This image shows the difference between Scrum and Kanban flow. You can easily see whether a Scrum team is at the beginning or at the end of a sprint.

In Scrum you work in iterations called Sprints. In Kanban there is more of a constant flow

So which one, Scrum or Kanban, is the best?

That depends on the circumstances; let us tell you a story from our past to explain what we mean by that.

Some years ago, I (Tomas) was working in a team that was doing Scrum. It worked well until we got to a point where we were about to develop support for new equipment. We had a deadline coming up but the purchasing department had not been able to choose the supplier of the new equipment. I remember a print planning meeting where item after item was refused, as we didn't know how to develop drivers without knowing the supplier (items can also be called user stories). In Scrum we are supposed to give a forecast of what we would release at the end of the sprint after the sprint planning, and without knowing the supplier we couldn't give a forecast.

I suggested that we should try Kanban because it can handle just-in-time planning. We changed method and managed to get to know the supplier in the last seconds and luckily we were done in time. Kanban rocked.

The project we started after this was one of those where you think "it should work just like it did before but with the new hardware". The problem was that no one knew how it used to work. We solved it by testing the system with the new hardware one step at the time and fixed problems whenever they occurred. Again, we had a tight deadline but we made it. This made me think that Kanban really rocked.

After the second project we didn't have so much to do but fixing allot of less important small issues. Then I observed that the energy within the team was going down drastically and that even small things took time. I realized that without a goal, Kanban doesn't work very well. Scrum, on the other hand, has a built-in goal every sprint thanks to the forecast made as the output of the sprint planning. Even though the result of the planning should be considered as a forecast and not a commitment, most teams try a little bit harder just to make the forecast come true. By changing back to Scrum, we got the energy back to a high level again.

To summarize, Kanban works great with uncertainties but needs a goal while Scrum needs to have enough certainty to be able to plan a few weeks ahead.

Kanban does also have an advantage against Scrum when it comes to surviving organizational reluctance to changes. Kanban does not oblige you to change so much in the early stages of its implementation. It doesn't force you to change your organization nor your way of working, but instead provides a framework to make your organization work more effectively and efficiently. Indeed, you may well implement larger changes later, but if you do that it is because the flaws in your current organization or process have been made obvious by using Kanban.

Our advice is to not get too religious about the difference between Scrum and Kanban. Most Kanban teams we have seen have a Scrum Master, but they call it something else. It also common to have a Product Owner, meetings like Daily Standup, demo and Retrospective, and terms like "backlog" and "impediments". All this is borrowed from Scrum. Actually, there is no rule or practice in Kanban stopping you from working in iterations just like in Scrum. At least as long as working in iterations improves your flow.