Project Management Methodology: Kanban

“It is not the strongest of the species that survives, nor the most intelligent, but rather the one most adaptable to change.” – Leon C. Megginson.

The name ‘Kanban’ originates from Japanese [看板] (pronounced as “kanban”; totally mispronounced by the Western world) and translates roughly as “signboard” or “billboard” (as I provide examples of Kanban boards, you’ll see why).

Kanban first appeared as a system of labeling parts used on assembly lines in production at a Toyota factory and goes side-by-side with such concepts as “just-in-time delivery” and “lean manufacturing” that all come from the Toyota Production System (TPS).

The Toyota Production System

The Toyota Production System, originating in Just-In-Time Manufacturing (JIT) was developed between 1948 and 1975 by Taiichi Ohno, and Eiji Toyoda to achieve better efficiency at Toyota. Taiichi Ohno is the father of TPS (which was adopted in the U.S. as Lean Manufacturing) and created the “Seven Wastes” model, which can be considered the core of JIT and Lean. Eiji Toyoda is believed to have led Toyota to worldwide prominence and is called “the Japanese Henry Ford”.  The principles the two developed became what is now known as The Toyota Way (2001).

The Toyota Production System (TPS) goes like this:

The Essence of Kanban

The Toyota Production System presupposes using the resources in the most efficient way, thus saving the resources that would otherwise become muda – “waste” or “uselessness” in Japanese. This idea is kinda close to the concept of 80/20 – not everything we do provides value, and we should focus exactly on those things that do.

Toyota Seven Wastes

1. Waste of overproduction (largest waste)
2. Waste of time on hand (waiting)
3. Waste of transportation
4. Waste of processing itself
5. Waste of stock at hand
6. Waste of movement
7. Waste of making defective products

The main objective is to eliminate these wastes. Here’s how it’s done:
As Toyota describes it: “Just-in-Time” means making “only what is needed, when it is needed, and in the amount needed.” The following is achieved by using the Kanban cards – cards containing the description of the parts needed (part number, order quantity,  shelf location, etc.) that are circulating among the workers.

Here’s an example of that. Say, a Toyota worker is responsible for attaching bumpers. He has a number of bumpers in stock (the exact number needed at a given moment) which he is currently using. Let’s say he has 20; when he comes up to 10 bumpers left, he knows he will soon need more, so he writes a Kanban card to the bumper supplier so that he gets the new ones just in time when the old ones run out. It is also called “the supermarket method”, as the idea was taken from the way the supermarkets are organized.

This way, everyone works upon request, producing/using the exact number of parts/cars that are requested. No excessive parts are produced, and none are kept at storage facilities for too long, resulting in reduced storage costs (thus reducing the prices for the cars, too). If you think of the fact this system works at every stage of production and then imagine the scale of Toyota, this will give you an idea.

Sounds awesome, but how can it be applied to, say, software development or marketing? That’s a reasonable question; it actually can, and it works quite successfully.

Kanban in Action

Kanban is a technique that stands above the processes in use within the team, and which improves these processes by setting some restrictions/making alterations (like limiting Work In Progress). What brings it closer to the essence of Agile is that it changes how the teams (and thus whole organizations) function. If applied properly, it stimulates self-organization, mindfulness, and – which is particularly awesome – “effective use of resources”, meaning that people actually start working exactly on what they should be working on, not every single task there is plus a couple of ones from a different person – which doesn’t at all depend on the area or department.

For example, when talking about Kanban in development, we also speak of “eliminating waste”, but in this case, “waste” is ineffectiveness caused by multitasking, unclear priorities, and stress.

The main idea is to A) minimize the work in progress at any given moment, because if many activities are performed at once, it inevitably influences the quality of each of them B) visualize the work so each employee knows exactly what is needed from him/her without unnecessary overwork, and there is a possibility to foresee the issues before they start scaling.
To achieve this, a board is used to visualize the tasks. It’s usually just a whiteboard that has columns on it. Sticky notes (aka Kanban cards) of different colors are used for each work item (just different colors if you use project management software), i.e. task (based on their type), and they are moved from one column to the following one as the work goes on. At Easy Projects, we’ve taken the whiteboard to the computer screen and made our Activity Center behave the same way.  A basic Kanban board looks like this:

You put the tasks on the to-do list, then you move them – a piece of cake.

In development, it sure is a bit more complicated, but the idea stays the same – there is a number of tasks to accomplish, placed in the matter of their priority. IMPORTANT: There is always a finite number of tasks, usually calculated empirically, and this number cannot be exceeded because it will deny the whole idea of Kanban. As mentioned previously, it’s important that Work In Progress doesn’t stretch itself to infinity and beyond, causing clutter and chaos, it should be limited to the absolute possible minimum (which is set by every team individually based on previous experience). If any changes appear, the system adjusts itself to those: the team can see where a bottleneck appears (before it’s critical) and finds ways to keep the whole thing going.

Why use Kanban?

Because it improves the quality of the end product AND helps the team stay motivated, by:

1. Knowing exactly what to do
2. They don’t get overwhelmed by a huge flow of tasks coming at them
3. They can see the pain points at a glance

Kanban is often mixed with other project management methodologies (see Scrumban, Pomodoroban). Our team uses the Scrumban approach, and they say the key is to find a methodology, or several ones, that works best for your team and the kinds of projects they have because there is no cure-all solution.

Any comments on how you and your team use Kanban? We would love to hear your story in the section below!