Get to the Forefront of
Agile Innovation

As part of our commitment to excellence and innovation, we’re inviting you to join our exclusive 365-day free beta program. This is a unique opportunity to experience firsthand the transformative impact scagile can have on your agile project management processes, at no cost.

What Is Kanban and How Does It Compare to Scrum?

Kanban Board in scagile - what is Kanban?

Contents of this article

If you search for the difference between Kanban and Scrum probably at least 10 000 search results with various articles and blog posts will come up. Despite the enormous amount of information on this topic, people still find it hard to understand the difference, and perhaps this is why you also landed on this article.  

That is why, to avoid any confusion, I will explain it in a very simple manner. And by simple, I mean really simple! 

What is Kanban and what‘s the difference between Kanban and Scrum?

Kanban is Scrum without commitment! Nothing more and nothing less. The whole ideology of Scrum is about developing releasable features on an iterative and incremental basis with the aim of delivering the highest possible value in the shortest possible time. So, if you take all of that and remove the commitment part, you get a Kanban process.  

Commitment is one of the 2 main values of Scrum; the other one is Completion. The details of what they mean and why are they so important, you can read in this article. 

To build on the above-mentioned article I would add that these values concern not just Scrum but Agile in general. After all, Scrum is a framework that aims to help teams to become agile. Business Agility is all about releasing on demand, developing customer-centric solutions, and keeping time-to-market. All these things require the team to develop the product vertically (feature by feature) and for the work to be fully completed before moving to the next step, so it can be released as soon as possible and feedback can be collected – that’s completion. 

How does Kanban work without commitment?

Okay… so completion is essential in an agile environment, but what about commitment? After all, commitment is the thing that we are giving up on when doing Kanban.   

Well, the two values, or more precisely, the practices that enable them, are instruments that support the agile way of working. So, it’s only logical that it becomes much harder to stay on the agile path when you disregard one of these values. 

My experience with Kanban teams proves exactly this. Many people assume that Kanban is much easier to do, but in reality, it’s quite the opposite. It requires much more discipline and effort, of course only if you want to do it right.  

In a Scrum process, you have more guidelines, “rules”, and principles (including commitment), which initially make the learning process more difficult, but they actually serve as tools and guides to stay on the right track. In the long run, they give you the gift of planning capability, which commitment offers. And planning ability is the other side of the medal of keeping time-to-market.  

I’m not saying that Kanban teams are incapable of keeping up with the market release, but it will be very difficult for them to do so. 

At this point, I would like to point out that I use commitment in the sense of “giving a precise commitment on what tasks can be completed in the next 1-2 weeks”. Even in Kanban teams, some form of commitment must be made, whether it’s at the level of releases, quarters, or tickets solved per day, so we cannot and do not want to relinquish all forms of accountability. 

Who does Kanban work best for?

Kanban acknowledges the fact that not all teams are capable of commitment. Service teams are a great example of this. The work of such teams depends entirely on the other teams in the project and can be completely unpredictable… I know, the nightmare of every agile practitioner! 

So, you can’t commit, but you also don’t want to give up all the other good things associated with agility, like effectiveness, completion, short feedback cycles, fast delivery, etc., and go back to Waterfall, and this is where Kanban comes into play.

What does Kanban look like in practice?

Kanban Board in scagile - difference between kanban and scrum

Abandoning commitment in the sense mentioned above means giving up some of the rituals and best practices in Scrum, such as Sprints and Plannings. Some organizations even go so far as to abolish the role of the Scrum Master. 

As the name suggests, this role’s responsibility is to take care of the Scrum process, so many think: “If there is no Scrum process to adhere to, we don’t need a Scrum Master” (hint: this is not a good idea). 

I want to say here, that this is the reason why I don’t find the naming of this role very suitable, and that it would be much more fitting to call this person, for example, a team coach, but that’s another topic. 

My point is that in a scenario where work arrives in an unpredictable manner, Kanban is your only option. It will allow you to visualize, prioritize, and assign work, keep track of the throughput of your team, while still respecting the fact that due to the nature of your work, you’re unable to make a reliable statement about which exact tasks you can complete in the next two weeks.  

To achieve all this, teams in Kanban use a Workflow Board to create transparency. Just like in a Scrum process, they have Dailies and Retrospectives. One difference between the two processes can be found in Planning, which is replaced by a Replenishment meeting. The goal is to ensure that the pulling work principle is enabled without being tied to a specific time box (Sprint).  

Also, the Review meeting in a Kanban process is slightly different. The agenda and the idea behind it remain unchanged; the only difference is that we don’t go into the Review expecting the team to have completed all the tasks planned for the iteration because there was no iteration. 

Another noteworthy point in a Kanban process is the principle of limiting WIP (Work In Progress). You simply set a maximum number of tasks that can be worked on at any given time. It’s as simple as it is effective because it ensures that the team stays focused and delivers value as quickly as possible. 

Which method is best for your team – Kanban or Scrum?

In summary, and to clarify any confusion about which framework to choose: If your goal is to achieve true business agility and you have no problem with unpredictable work, then you should opt for Scrum. 

If you stumble upon the second half of the relation, then ask yourself: “Is there really no way to make my team’s work predictable through process improvements, etc.?”. Take time to ponder over this question, do a few iterations, discuss it with an Agile Coach, and if the answer is still no, then you should go for Kanban. 

Don’t get me wrong, I have nothing against Kanban, but it’s just one step away from true business agility, and the path of agility is already so full of pitfalls, traps, and holes that we don’t want to risk it even more. 

The app for scaled agile teams is finally here!
Click here to see articles with the same tags:
Gergana Petrova
Gergana Petrova is an Agile Coach with over 5 years of diverse experience as a Scrum Master, Release Train Engineer and SAFe Program Consultant. Having worked with organizations such as Deutsche Bahn, PWC, E.ON, and Misumi, she has gathered insights into the unique challenges and opportunities presented by each environment.

Gergana also develops innovative techniques and tools aimed at empowering organizations in their transformation journey, like our own Job Size Calculator.

In addition to her work experience, Gergana serves as a lecturer at the TU Sofia, where she inspires the next generation of agile practitioners.
More interesting articles for you: