As part of our commitment to excellence and innovation, we’re constantly developing, testing and launching practice-proven features to help your organization stay and scale agile. Therefore, more exciting features will be launched soon. See our upcoming features in the list:
Tips & best practices:
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!
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.
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.
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.
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.
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.
What is it that renders the role of the scrum product owner so problematic and how should it be designed to allow an agile transformation to succeed?
Should Agile teams estimate in hours or days? Here is our honest opinion on this controversial topic regarding time estimations.
With the WSJF technique, prioritization and PI Plannings become damn easy, highly effective and even fun! Step-by-step guide and free WSJF Excel template
Where value flows & business aligns –
The first AI-powered scaled agile project management tool.
