Kanban vs Scrum? Which method leads to success?

Kanban vs Scrum
The question of which agile method is suitable for which project is not always easy. We try the comparison Kanban vs Srum.

Advantages and disadvantages of agile working methods

Those who decide to work agilely are spoilt for choice when it comes to methods. Kanban, Scrum or Lean Management are just a few of the keywords that are on everyone’s lips. Often, it is Scrum with its precisely timed sprints and user stories that those in charge choose. Whether this decision was the right one sometimes only becomes clear after a long process of trial and error. How can such a mistake be avoided?

Decision criteria for agile development methods

There is no generally valid answer to this, but some criteria can help to make a reorientation in the middle of a work process. The best way to explain this is to use a negative example in the case of a choice between Kanban and Scrum. Because it is also true in agile working that mistakes are the best teachers.

In our case, the client was faced with the challenge of organising a team that worked at different locations and whose participants did not all speak the same language. In other words, the best conditions for agile working. The task was to further develop a product that was in operation. Therefore, the choice of agile method fell on Scrum. With its clearly structured blocks, sprints and firmly outlined requirements described in user stories, this method is very popular in product development.

Adapting the agile approach

In our case, however, exactly what is otherwise an advantage became problematic: the requirements, which were precisely tailored to the team, did fit the mandate to further develop the product. In addition, however, the team had to take over the ongoing operation and support. As a result, critical defects were repeatedly added to the already existing tasks, the processing of which could not wait until the next sprint. The workload of the individual team members increased, as they felt obligated to their commitment to the user stories.

An adjustment of the method became necessary. After careful consideration, the decision was made to implement the task with Kanban. From then on, both the further development and the ongoing operation ran without further problems. But why was the Kanban method better suited than the Scrum method in this case?

Difference Scrum Kanban

It makes sense to look at the fundamental differences in the methodology of the two approaches. On the one hand we have Scrum. Here, precisely specified scopes of work are defined for a certain period of time and the progress is communicated in the daily routine. Here, it is not planned that the requirements change in the course of a sprint or that more are added, which works wonderfully well with a precisely outlined task without “disruptive factors”.

The Kanban method, on the other hand, is primarily about establishing a continuous flow of work. For this purpose, the individual work processes from the idea to the completion of the task are made visible in various so-called status columns. The starting point is usually a collection of prioritised pending issues, which are drawn up by the individual team members themselves. The ingenious thing about this is that only a certain number of tasks may be listed under the individual headings of the tables, i.e. it is not possible to start any number of new tasks before others have been completed.

Advantages of the Kanban method

This leads to tasks being completed, but unlike Scrum, it allows new requirements/ideas to be fed into the process. Of course, prioritisation of tasks and monitoring is necessary so that no “task corpses” are left on the way to completion. The product owner is responsible for monitoring the continuous process to ensure that no tasks are left undone.

Another difference is the focus of the dailies. While Scrum focuses on the team members, Kanban is more about organising the tasks and finding solutions to problems that arise.

More flexibility and faster work flow through Kanban

In our case, it became clear that Kanban had to be the method of choice because it fulfilled two requirements that were necessary for the successful implementation in the client’s sense: it was possible to feed in newly arising problems and, by focusing on the workflow, it guaranteed that both the activities that could be planned in the longer term and those that were newly added were completed.

What we have learned from this is that it is important from the beginning to examine exactly which factors play a role in the completion of a task in order to find the appropriate method. In keeping with the spirit of agility and the fault tolerance implicit in it, the courage is required to revise and reconsider a decision that has already been made if it becomes clear after the application has been launched that one has made a mistake in the choice of method.