This is the second version of the blog. Since I’ve published the first version, I’ve received a lot of valid criticism on Reddit, including comments like these:

(also my animations sucked)

I did my best to address these and other comments below. The metaphor is fixed, there is no unnecessary terminology, and finally – there is a simulation.

Misunderstanding Kanban

To my big surprise, a lot of managers completely misunderstand Kanban. Here are a few things that I’ve read in reputable blogs or heard people say, all while they were wearing very serious faces.

• Kanban is a system like Scrum, only there are no sprints
• Kanban introduces work-in-progress limits so that the developers “don’t multitask” (i.e. to control developers’ behavior)
• Kanban is a board that.. (further content irrelevant)

So if not all these things, what is Kanban? Let’s take a look at Kanban as a visual signalling system that helps find and address process inefficiencies.

A buildup of work-in-progress is exactly the signal that indicates an inefficiency. Setting a limit on WIP is a mechanism that triggers action (which ideally should go beyond “let’s just not take any more work until the team is done with their current workload”).

Let’s take a look at an example a simulation. This simulation is designed to be intentionally simplified and serve as an illustrative example of how the flow can significantly change depending on the process rules and parameters.

Let’s see how it plays out

If you want to play with the simulation first, you can start right here. Try and see how various workflow rules handle the “normal”, “hard”, and “insane” flow. Switch the animation off to get the results faster.

(or open StackBlitz in a new tab).

Here’s some explanation.

The simulation models a simple process where orders (tasks, work items – represented as boxes) are processed at multiple workstations in a sequence.

Every workstation has a waiting queue (low shelf) and a processing desk. One person is initially assigned to every workstation. In all simulated workflow rules, people at workstations never multitask. Every person will always process at most one order at a time.

There are three “games” you can play with the simulation.

1. “Passive”. In this simulation, the people just process the orders. They don’t try to organize themselves, they never move workstations, and they stay at their places until the end of the simulation.

2. “Manager decides”. In this simulation, the people are organized by a simple decision-making script (“a manager”) that executes the following logic:

   • If someone is overloaded (there’s a parameter that defines the overload threshold), get help by reassigning a few people from other workstations who are loaded the least.
   • If someone is underloaded, send them to help to the most overloaded workstation.
   • If the load at a workstation has normalized, send all the help to their “home” workstations.

   The manager has a limited reaction time, which you can change in the simulation parameters. The reaction time influences how soon the manager would “notice” abnormal load, and how often they would make decisions.

   In this simulation game “the manager” has to know the situation at every workstation at the same time.

3. Kanban. In this simulation, the people don’t require centralized management. Instead every person observes exactly two queues – their inbound queue (on the left) and their outbound queue (on the right, the same as the inbound queue of the next workstation).

   Observing just these two queues, the workers are able to take one of the following decisions:

   • If their inbound queue is empty, move to the left, to help at the previous workstation.
   • If their outbound queue exceeds the WIP limit, move to the right, to help at the next workstation.
   • If their inbound queue is normalized, make a step back to their “home” workstation.

   Note that these rules do not require any of the workers to have the knowledge of the entire line. Instead the knowledge and decision-making is local, limited to the two boxes on the right and on the left of the person (I’m using left-to-right sequence in the simulation).

   Also note, that this setup is not what Kanban is, but rather an example of how actionability in a Kanban system can be implemented.

Other things you can do with the simulation

Click on a workstation to simulate it being “broken” (it would start to process orders x10 times slower). In addition to this manual control, the model will break and fix workstations from time to time to introduce more irregularity in the flow, allowing you to observe how different models recover from this.

Feel free to fork the model, change the business rules, and explore their influence on the outcome.

Kanban at Toyota

Kanban was not initially designed for Agile software development. This method was developed by Taiichi Ohno, an engineer at Toyota in the fifties.

Here are a few quotes from “Toyota Production System: Beyond Large-Scale Production” – a book by Taiichi Ohno. I took the liberty of highlighting the places relevant for this blog.

On the principles and the value of Kanban as a “pull” system:

We experimented with this and finally decided on a system. The final assembly line is taken as the starting point. On this basis, the production plan, indicating the desired types of cars with their quantity and due date, goes to the final assembly line. Then the method of transferring the materials is reversed. To supply parts used in assembly, a later process goes to an earlier process to withdraw only the number of parts needed when they are needed. In this reverse way, the manufacturing process goes from finished product back to the earliest materials forming department. Every link in the just-in-time chain is connected and synchronized. By this, the management work force is also reduced drastically. And kanban is the means used for conveying information about picking up or receiving the production order.

You might have noticed that in order to implement a Kanban system in a way similar to the one shown in a simulation, workers have to possess multiple skills to be able to replace each other. While this is not the only way to implement the system, here are a few relevant quotes from Taiichi Ohno that show the same intent:

In the American system, a lathe operator is always a lathe operator and a welder is a welder to the end. In the Japanese system, an operator has a broad spectrum of skills. He can operate a lathe, handle a drilling machine, and also run a milling machine. He can even perform welding. Who is to say which system is better? Since many of the differences come from the history and culture of the two countries, we should look for the merits in both.

By the way, adoption of this culture did not go without resistance.

Our craftsmen did not like the new arrangement requiring them to function as multi-skilled operators. They did not like changing from “one operator, one machine” to a system of “one operator, many machines in different processes. Their resistance was understandable.

The only operations factor that matters is the flow.

…the idea is teamwork - not how many parts were machined or drilled by one worker, but how many products were completed by the line as a whole.

On allocating people to produce maximum output and react promptly on process inefficiencies:

In a manufacturing job done by four or five people, the parts should be handed over as if they were batons. If an operator in a later process is delayed, others should help set up his or her machine. When the work area returns to normal, that worker should get the baton and everyone else should return to their positions. I always tell workers they should be skillful in baton passing.

What’s the conclusion

The main point of this post is to demonstrate how Kanban works as a signalling system that helps improving the flow.

While I’m not saying Kanban can’t do that, I think it’s important to mention that Kanban fulfils this purpose not through managing stress, collecting statistics, or preventing overwork – but through using the buildup of work as an indicator of an inefficiency, prompting the team to take action.

Credits

The simulation is done using Simscript for JavaScript by Bernardo Castilho.