Scrum vs Kanban: Which Should I Use?

When I am teaching Scrum courses, I often like to ask attendees: Is anyone using Kanban? More often than not, a number of people on the course will say: Yes we have Kanban boards. So I say: Great! Have you mapped your workflow on your board, and are you applying WIP (Work In Progress) limits? To which the answer repeatedly is: No, we just use a Kanban board.

What follows next is that they want me to explain the difference between Scrum and Kanban. Which is when I normally get the question: Should we use Scrum or Kanban?

Let’s look at some of the possible deciding factors.

Need to kick-start an Agile transformation?

Scrum

Scrum is a lightweight process framework for managing complex product development. It only has 3 Roles, 3 Artifacts, and 5 Events that provide the foundation for the Agile way of working. When implemented correctly, it can get you a long way from a standing start.

Kanban

Kanban does not provide any roles, artifacts, or events to follow. You simply start by visualizing the work you are doing and the process that the work is going through, without any changes to it or to the existing organizational structure and roles. You then start to balance the demand and delivery capability by limiting work in progress (WIP) and monitoring the flow of work, in order to identify issues and evolve the process on an ongoing basis.

Kanban is initially less disruptive than Scrum as it starts with the existing process and structure. However, an Agile transformation fueled by Kanban would typically take more time.

Think about the wider system, not just product development

As already mentioned, Scrum is a process framework for managing product development and it only really deals with improving this part of your end-to-end system. Kanban systems can visualize work from the moment it enters your system (i.e. is requested by the customer), through to the point that the work is done (delivered to the customer).

So you could say Scrum only deals with part of your system, whereas Kanban covers your system in its entirety, from ideation, right through to the delivery to your customer.

Consider the rate of which a team’s work changes

Scrum is a timebox-based system. A Sprint length is set in advance and kept stable, and work is planned for that agreed period of time. The Scrum Alliance says a Sprint can be one month or less in duration, but most teams nowadays appear to have standardized on two week sprints. If a new, urgent, requirement were to emerge after a Sprint has been planned, then the customer would have to wait at least until the following Sprint for their work to be started.

Kanban does not have the concept of a timebox. Instead, work flows through the system in a continuous fashion. Kanban can be implemented with regular replenishment cadences, but recognizes that the best way to replenish work into the system is on demand. On-demand replenishment in Kanban would mean that the customer’s new urgent requirement could be put into the system as soon as there is available capacity within the agreed WIP limits.

If you cannot commit to a Sprint plan for the next Sprint without there being a need for change, then Kanban may be more suitable for you. We often find that teams responsible for support or business-as-usual (BAU) fall into this category.

We need to stay in control

Many organizations, especially the ones that are larger and more established, appreciate control and are risk averse. Implementing an Agile method like Scrum requires a culture that supports the Agile mindset, and allows the teams to collaborate, take ownership of their work and learn how to work together and improve.

Conversely, Kanban can be successfully implemented in a strong control environment. The initial Kanban implementation is less disruptive compared to implementing Scrum. The Kanban system will then only be changed based on evidence of system behavior, which a control culture would be more amenable to.

Can we combine Scrum and Kanban?

Well, yes.

I often find that implementing Scrum is a good place to start for a team adopting Agile. It provides you with the clear guidance of the minimum you need in order to ‘be Agile’ in terms of roles, artifacts, and process in the events.

Then, as teams mature, using Kanban can be a great way to visualize, control and improve the work a team does during a Sprint. This is called ‘Scrumban’- a hybrid of Scrum and Kanban.

You can also start to look at the wider system, not just the product development part. Start to extend your Kanban system to look at the work that happens upstream and downstream of the development team. Furthermore, you can use Kanban to start managing the work at the program or portfolio level in an organization.

Summary

There is no right or wrong way.

It is important to assess your current context, decide what outcomes you are trying to achieve, and make an informed decision of how you are going to design your initial Agile Operating Model (AOM).

Scrum is a great starting point for your AOM, and may be all you need.

Kanban can then be used to visualize the development work to the further level of detail, extend the visualization to the entire end-to-end system and, most importantly, identify areas of your system that need improvement.

While there is no single right answer overall, you should look for a good answer for you in your specific context.