Between Scrum and Kanban. First: A Few Words on the Nature of Demand
We’re launching a new product team; should we choose Scrum or Kanban? This question, in one form or another, has been haunting me for at least the last ten years. Most professionals working with teams frequently encounter this inquiry. Google or YouTube search reveals thousands of articles and videos detailing the differences between Kanban and Scrum. They offer an overwhelming number of recommendations for choosing between them.
At this juncture, I feel compelled to “activate consultant mode” and start explaining the choice. But let’s first analyze the request. Why do teams face this dilemma? Why there is a choice dichotomy specifically between Scrum and Kanban? How are the team’s real needs connected to this choice? Each answer here merits its article. Ponder these questions.
When the Choice Arises:
The most typical scenario is the launch of a new team. However, it’s important to pay attention to the details. When a team’s maturity level is high enough, they can figure out their process and select suitable practices and tools on their own. The question of choice then becomes more specific, dealing with issues like, “How do we handle urgent requests from our users daily without losing focus on creating valuable increments?” When internal maturity is lacking, it becomes necessary to impose a ready-made structure and develop the team from a certain baseline. How best to name this basic structure will be discussed in the second part of the article.
Another common situation that leads to the request for a “methodology” (quotes intentional) is when the current workflow fails to allow the team to address their tasks. As a result, the team runs out of ideas for its improvement and development. In my observations, product teams most often encounter this during transitions from one stage of the product lifecycle to another. Teams delivering value in a service paradigm and project teams may also find themselves in such a situation, requiring radical process changes. Simplifying the picture, the request for managerial practices arises either in response to problems in the workflow or due to the team’s insufficient maturity, which prevents evolutionary process development and necessitates externally provided guidelines.
However, this is not an exhaustive list of reasons. I often encounter situations where the choice between Kanban and Scrum is imposed on teams from above for the so called noble purposes, such as alignment. External consultants frequently act as agents of this imposed choice. Some of them are genuinely mistaken, believing, for example, that “Kanban is for support teams” or that one can “manage projects using Scrum.” For others, this choice is a manipulation tool – their goal is to tip the scales in favour of the tool they wish to use. In any case, I see nothing positive in such actions performed by consultants.
Between Scrum and Kanban: The Choice without choice
Thus, we’ve examined the nature of the choice between Scrum and Kanban. We’ve discovered that the basis of the request is the desire to obtain a ready-made solution and a working process that best fits the team’s context. Now, let’s take the next step – to understand what we are actually choosing from.
Scrum: The creators of the Scrum framework define it as follows:
“Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions for complex problems.”
No more, no less. While I don’t fully agree with this definition, preferring the one from the previous version of the Scrum guide, let’s not argue with the authorities.
The essential point here is that Scrum is, by definition, a process framework. It is a set of mandatory values, artefacts, events, roles, and the logic of interaction between these entities. Scrum is not just sprints with story points; it’s a specific logic of value delivery, into which all the elements described in the guide are woven.
So, if a team says that they use Scrum as their working process or that they want to use the Scrum framework as their working process, this is a perfectly valid formulation.
Kanban: Let’s see what is written in the Kanban Method Guide:
Kanban is not a methodology nor a process framework. Rather, it is a management method or approach that should be applied to an existing process or way of working. There is never a question of using Kanban versus a given methodology or framework. Rather, it is always adding Kanban to an existing methodology, framework, or way of working. Kanban is intended to help you manage work better and to improve service delivery to the point where you consistently meet customer expectations.
Kanban is not a standalone process! Kanban cannot be an alternative to Scrum or any other process. Kanban is not a process framework but a set of tools for improving the existing process. These tools can be applied to any process but not to chaos.
That is, Kanban can be used alongside any other framework but cannot be used instead of a framework.
Between Scrum and Kanban: Maybe Better Together?
We’ve established that Kanban cannot be considered an alternative to Scrum since the Kanban Method helps improve an existing process rather than replacing it. So, what does a proper inquiry about Scrum and Kanban from a team look like?
Is it possible for us to work with Scrum in our case? This is a good question. To find a solution, one must study the characteristics of applying the Scrum framework and try to adapt Scrum to the context of your organization. However, remember that Scrum cannot be “adjusted” to fit existing organizational dysfunctions and limitations.
Can we improve our Scrum with practices and tools from the Kanban Method? This is also a valid question. The Kanban Method offers a simple and understandable path to the evolutionary improvement of services through its principles, tools, and practices. For example, using Kanban’s task flow management within a sprint can significantly increase the likelihood of achieving the sprint goal. This approach is described in the Kanban Guide for Scrum Teams by Scrum.org. A Scrum Team can apply Kanban principles of intellectual work management and visualization tools also to optimize product backlog work.
Moreover, Kanban does not require a “pure” Scrum process. You can start benefiting from Kanban with any formalized task execution method, fully aligned with the Scrum guide or not at all considered Scrum. Any process, except chaos, can be enhanced.
It’s time to draw conclusions.
When the question of choosing between Scrum and Kanban arises within a team, it either indicates the team’s insufficient maturity or a transition to a new stage in the product lifecycle. External consultants and coaches often prompt teams to make this choice without fully understanding the specific problem they are trying to solve.
The choice between Scrum and Kanban itself is meaningless because, by its very nature, the Kanban Method cannot be an alternative to Scrum. It can be used in conjunction with Scrum or any other process framework, but not as a complete replacement for Scrum.
Moreover, it’s important to note: Scrum and Kanban focus on the same thing – Value Delivery. This in itself is a strong argument for their combined use. Scrum serves as a framework for delivering value, while Kanban provides tools and practices to improve value delivery.