Scrum x Kanban

What process structure should be implemented in a project? Read the article and learn more about Scrum and Kanban methodologies!

By Luciano Osorio – Scrum Master at Zappts

Recently, a client was seriously considering adopting the Scrum methodology, but in a quite particular way.

Priorities would change all the time, the team would be partially allocated with people shared across multiple projects, and sprints should be one week long.

He asked me to help make this model work.

Given the scenario described, I recommended the Kanban method as the most suitable, however, the suggestion was not accepted at first. So, I continued studying the best possibilities.

One of the problems faced in this client’s projects was the lack of visibility into how much work was actually being done and how he could improve process execution.

I maintained the recommendation and suggested we try Kanban for a few weeks.

Now, you might be wondering: but what is the reason for the insistence on Kanban?

Well, I’ll explain why this recommendation and take the opportunity to clarify the main differences between Scrum and Kanban.

Keep reading to find out!

Scrum x Kanban: The difference is in commitment and focus

Let’s start by understanding the difference between Scrum and Kanban and which criteria to evaluate for an assertive and effective choice.

Scrum

In Scrum, the team commits to the product. Every sprint has an objective to be met, which takes the team one step forward in delivering product value.

The team estimates the work to be included in a sprint and commits to doing that work with the highest possible quality. No interruptions or priority changes.

Focus on the sprint objective is the main theme of the team’s daily meetings. They should be held with the purpose of identifying problems that prevent reaching the objective and proposing solutions to remove them from the processes.

At the end of a sprint, the work the team committed to is evaluated and accepted as a product value increment.

The team follows with an assessment of how the work was carried out during the sprint and plans actions to work better in the next one.

To learn more about what Scrum is, I recommend reading this article, available on our blog.

It’s very comprehensive content with good references to dive deeper into the subject 😉

Kanban

In Kanban, the team commits to the flow, that is, to the rhythm at which the completed work moves through the process steps.

It is necessary to identify the factors that influence the flow and work to always improve it. This way, it is possible to ensure that work does not get backed up while waiting for some step.

It is necessary to understand the slowest step and align the rhythm so that it occurs smoothly, without buildup.

Furthermore, in Kanban team members execute one piece of work at a time. This focus helps greatly improve the quality of the work performed.

Here, priority changes can occur freely, because when selecting the next piece of work, each team member will always choose the most prioritary one at a given moment.

And for the team? What is better: Scrum or Kanban?

The answer will depend on the context.

In both cases (Scrum and Kanban), multidisciplinary teams execute the work.

The relationship between team members following agile values is fundamental in both cases, as is leadership that makes clear the purpose they should pursue, motivating them to always deliver their best.

In the case of Scrum, the framework structure with time-boxes creates the notion of beginning, middle and end at each sprint, which produces the feeling of reaching an objective.

In Kanban, the flow is continuous and because there are no time-boxes, each flow improvement achieved by the team should be celebrated, keeping the focus on continuous improvement.

Focus on the right thing, having clearly defined objectives aligned with team values is always the best, and this can be achieved with Scrum and Kanban.

But what about control?

Both models have control.

Specific metrics, such as Sprint Burndown, show the Scrum teams’ progress toward the objective daily, and metrics like “velocity” help with delivery predictability.

In Kanban, the Cumulative Flow Diagram clearly shows which process steps increase Lead Time and therefore need attention.

The Flow Efficiency metric shows the relationship between time spent on steps that are bringing value and those that don’t, but are necessary for process control, such as inspections, backlogs, etc.

Therefore, again, as long as with the right focus, Scrum and Kanban offer metrics that help with process control and predictability.

Scrum x Kanban: And the winner is…

Now that I’ve explained a bit about the differences between Scrum and Kanban and how to evaluate the most suitable option, it’s time to answer the question in the title of this article:

Scrum or Kanban: which is better?

Well, as we’ve seen, there’s no winner in this “duel”. What there is is a need to align the choice with the context, committing to what makes the most sense.

If we’re dealing with a product team, with a defined purpose, a project scope that evolves, but in an orderly manner and with defined priorities, Scrum is recommended and can greatly help in achieving product objectives.

On the other hand, if we’re dealing with a team that handles variable demand, with priorities that change all the time and problems completing started work (which fits the situation of the client I mentioned, remember?), Kanban will help create a flow with a predictable rhythm.

I hope this information can help you understand Scrum and Kanban. They are methods applied to simplify processes, have more flexibility in meeting demands, and of course, improve team performance and integration.

Cheers and see you in the next article!