Kanban – a simple, flexible, and effective way to organize product development

Besides Scrum, Kanban is probably the most prevalent system for managing workflow in agile product development. It is a very flexible system, with little overhead. As such, Kanban is very easy to implement. Many enjoy the feeling of flow that results from using a Kanban system.

Anecdotally, many teams seem to be moving from Scrum to Kanban or using a mix of both. The most frequent reasons I hear seem to revolve around the rigorousness of the Scrum framework and the pressure that arises by the need to finish the sprint. Therefore, I want to dive into the Kanban framework. 

I will explain how Kanban in product development works and dive into the Why of Kanban. First, though, being a mechanical engineer by training who studied lean production, I cannot talk about Kanban in development without briefly diving into its roots within manufacturing. 

Email address:

Leave this field empty if you're human:

The origins of Kanban

The Kanban system is one of the core features of lean production and was invented by the Toyota Motor Company more than half a century ago. In its core it is a simple control loop that ensures only that is produced what is needed. As such, Kanban in manufacturing leads to drastically reduced stock and shorter throughput times.

Kanban translated literally means something similar to Card. The name comes from the fact that Kanban cards are the key component in this production scheduling system. In a nutshell, as soon as the number components needed as an input for a specific manufacturing step drops below a predefined level the Kanban card for that component is returned to the upstream process. This is then the signal to create an additional, predefined number of  input components. 

Nowadays in lean production, this is of course all done by software and the system has been adapted. Kanban and the core principle of pull based manufacturing, however, is still at the heart of lean manufacturing. 

Kanban in product development

Kanban was adapted to product development many years ago and, along with Scrum, is probably one of the most prevalent agile product frameworks in use today. The implementation of Kanban in product development is considerably different from manufacturing, as the nature of work is also considerably different.  

The underlying principles are what connect Kanban in development to the original implementation in manufacturing. As it does in production, Kanban in product development is focused on flow, pulling, and limiting the amount of “stock”.

The core of the system is a flexible board. There is a backlog of things to do on the left side and things on the right are done. In between are all the steps a user story or feature must go through before being done. These steps can range from the very simple (To-Do → Doing → Done) to the extremely complicated. It depends on the type of work and the team´s preferences.

Essentially, the team picks the highest priority items from the backlog and moves them through the process, from left to right on the board. An important point to mention here is the maybe most important feature of the Kanban board, limiting the total number of stories that can concurrently be in one process step. 

This constraint means the team is only able to pull a task from the backlog after finishing another. By limiting the amount of work in progress, a Kanban system helps teams finish developments before starting something new. This is probably the main driver for creating the feeling of flow when using Kanban.

Why use Kanban in product development

Kanban in product development is a very flexible method in modern product development. There are good reasons for choosing this method. The most obvious is that it is a great tool for visualizing what is going on and the status of work in progress, one of the most important agile principles. I will not expand on that here since this is the benefit of using any type of board. I will instead focus on what makes Kanban unique. Four things stand out to me:

• Flexibility in application
• Dealing with uncertainty
• Little overhead
• No estimation

I will dive into these points one by one.

Flexibility in application

Kanban is in its nature extremely flexible. As mentioned above the board itself can be adjusted to include almost any type of (development) process. Therefore, Kanban is a great tool that can also be used outside of software development.

I have implemented Kanban tools for a team of mechanical designers, we have used it within a team of project purchasing managers, and to visualize the progress of several manufacturing locations that I was responsible for.

These are very different use cases, all of them very distinct and unlike one another. The Kanban board helped in all cases. As it is so often, it is about the principles. Agile means visualizing the work. A Kanban board fosters communication and is a great tool to identify bottlenecks and do something about them.

Anything that has a more or less defined process can benefit from using a Kanban board.

Dealing with uncertainty

Kanban is great if you are working in a volatile environment. Unlike Scrum, the Kanban approach does not include committing to a sprint´s worth of work upfront and uninterruptedly   focusing on this for several weeks. With Kanban, the backlog can be shifted around as much as you want, until the item gets taken by the team.

As such, this approach is great when priorities are constantly shifting. This may be the case when you have many bugs or customer requests (e.g. helpdesk). It could also be that you are dealing with changing requirements because you are at the very beginning of your product lifecycle and iterating very quickly trying to find product market fit. Or you might be dealing with leadership that doesn’t really know what it wants. 😅

In all of these environments, the Kanban approach works well. It is built so that the backlog of things to do can be shifted around to account for the uncertainty. 

Little overhead

The Kanban approach by itself only includes the board. There is no additional overhead. It does not include a review or any of the other Scrum ceremonies (although, I would argue that they can be extremely valuable).

As such, the method can be introduced very easily without burdening the team with many additional things to do. The team can then individually decide what types of alignments and regular “ceremonies” are needed.

It does make sense to mention here that little overhead also means more responsibility for the team to make these decisions. Not all teams are good at that. Some might need to be supported, at least in the beginning until they get used to the responsibility this freedom brings. 

No estimation

Kanban with its focus on continuous flow does not include estimation of tasks, user stories, or work packages. Anecdotally speaking, having to estimate seems to be one of the main issues people have with Scrum. That is why I am briefly addressing it here, although I have never witnessed these problems myself.

I am honestly not sure why it is the case but many teams seem to struggle with it. (My best guess is that not the estimation itself is the problem but that estimations are treated as something absolute or as commitments.) If you are in one of those teams it might make sense to try Kanban as it does not include the need to estimate how many story points a specific feature will be.

It doesn’t have to be Kanban vs. Scrum

Scrumban! That is often the answer I get when I ask peers if they prefer Scrum or Kanban. It doesn´t necessarily have to be either or, you can have the best of both by combining them. 

I enjoy and have had great success with Scrum. It is a powerful framework that might be too rigorous for some teams. Especially mature teams might not have the need for this rigor. Scrum with its pressure to “finish the sprint” can also sometimes lead to cutting corners in terms of quality just to get features out of the door.

Thus, I encourage you to combine the two approaches if it makes sense for you. You might do away with sprints and set up a Kanban board, keep a daily stand up and a bi-weekly retrospective. Instead of a review, you could have a monthly demo. The possibilities are endless.  

See what works for you, try it, and adjust. Remember, agile product development is not about methods. Its core lies in principles that you can adhere to regardless of the way the team organizes its work.

Coverphoto by Eden Constantino on Unsplash