Kanban or Scrum? Which one should I choose?
Kanban is a less-known methodology than Scrum. But it is more often considered as an alternative to Scrum. Indeed, there is an intersection between the application areas of these frameworks, but their characteristics have major differences. Therefore it is worth to overview which one to choose.
Of course, our principle is the same as always: being Agile.
Scrum and Kanban are not religions, hence polemics should be avoided, let’s just look at them like tools and try to find their place in the world as those.
Kanban’s lures and pitfalls
Kanban’s biggest lure is its simplicity. It has 3+1 rules in total:
1. Visualize the workflow.
2. Limit the number of tasks being in progress at the same time (Work-In-Progress (WIP) limit)
3. The goal of every contributor should be to help items move through the queue as fast as possible
+1: Pull, instead of Push, regarding the task handovers
That’s all. Seemingly trivial, and for this very reason, quite risky to fail it. The main risks are:
• It is easy to build a methodology which looks like Kanban. This is quite usual at organizations where it is enough to appear Agile on the surface but they do not want to really change. Naturally, on one hand this “solution” won’t bring any significant result on benefits but on the other hand it discredits the framework. It is the same situation with all the frameworks implemented, also like Scrum or others.
• Since it is a very allowing framework, one needs a lot of self-discipline to be successful with it. Organizations where the main reason for applying Kanban is its permissiveness eventually will break basic norms and even the three 3+1 rules in time.
When to use Kanban?
That’s why expert consultants advise using Kanban in product development only after Scrum already works well. If an organization can adhere to its stricter rules, then a more flexible framework can work as well.
We also use Kanban in another situation if conditions are not suitable for Scrum and it is needed that the obstacles should be clearly discovered. For example, in order to ensure that the team can indeed deliver a “potentially shippable product increment” at the end of every sprint, it is necessary to do the testing within the team.
We met a team which really wanted to work in Scrum but they had no testing competency and infrastructure. It took 4-5 days in average to develop a feature but the testing done by the central tester pool of the company could last 60-90 days. Of course, in this case Scrum is not a real option, but with a clean, well-functioning Kanban process we can reveal these bottlenecks and highlight the problem.
Besides the above mentioned experiences it is also important to emphasize that Kanban is a lot more than a potential alternative to Scrum in product development: it is an independent and effective method with quite serious preparations before its introduction. It can be useful in many sectors, in IT it is widely used for maintenance and support tasks, outside of IT it works in HR processes, supporting decision-making processes and sales. As a matter of fact it is possible to use Kanban independently from business domains (as one of our favorite simulation games proves it in a pizzeria); anywhere there is a process, a well-implemented Kanban can improve a lot.
Is it worth switching from Scrum to Kanban?
Summarized, in immature organizations Kanban can be a good pick to discover bottlenecks.
After that, until the conditions allow and the organizations gained the necessary maturity and discipline, we rather recommend Scrum. If it works already well, then can one consider Kanban – if it is needed at all (for example the set iterations can seem too binding and the business environment requires such a versatility that planning ahead of two weeks is already a constraint.
Of course this receipt is only a general guideline, decisions should always be made with taking the exact situation, conditions, circumstances, etc. into consideration, or with the help of expert agile coaching.