Kanban sucks!

Nigel Thurlow wrote a linkedIn post stating that the Kanban used in Agile Software Development is not the same as the Kanban used in manufacturing. Nigel is the most knowledgeable person I know on Kanban in manufacturing, based on his many years as a practitioner in Toyota. Nigel explains that his knowledge of the Kanban used in software is based on training software.

Nigel is correct. This is my “Yes, and…”

Kanban in Manufacturing

As Nigel states, the purpose of Kanban in manufacturing is to ensure that supply meets the demand of customers. In front of each work station is a pile of input goods (which may only be one item). When the pile is reduced to a certain level (e.g. only two items left), a card (Kanban) is revealed that is passed up stream to the work station that provides the input goods. The Kanban card is the signal that pulls the work from the up stream work station. The size of the pile of work in front of a work station is based on the balance between how long it takes the input work station to replenish the items and how long the pile will be completely depleted.

At Agile2009, Todd Little pointed that if only a single product with no variation is being produced for the customer, then Kanban is not needed and lean will suffice. The up stream work stream operator simply monitors the queue between it and the down stream workstation to determine when to replenish the queue. Kanban is used when there is more than one product variant.

In manufacturing, the design and manufacturing process are distinct. The physical good is designed in one process, and then manufactured in a separate process. This means that when a customer requests an item, the manufacturing process is completely known in advance. Furthermore, each customer request results in exactly the same manufacturing process, exactly the same steps, and the process can be optimised over time to match demand and supply, ensuring work appears “Just in time”.

In a manufacturing Kanban system, the work station stages are “Build” and “Deploy”. “Design” and “Test” are done as a separate process before the customer makes the request. This means that when a customer makes a request, it is possible to predict how long it will take to deliver. If a customer wants an item before it can be delivered, then it is known that this will overload the system and the customer must wait, or an item is expedited with a known negative impact on the effectiveness of the system.

Kanban in Software

Kanban in software was inspired by Kanban in manufacturing as a mechanism to limit work in progress as a way to match demand and supply.

In software development, the design and manufacturing process are NOT distinct. When a customer requests software, it must be both designed and implemented. The software is ONLY built once, though it is tweaked and modified to remove defects and add new variation over time. In software, the work station stages are “Design”, “Build”, “Test”, and “Deploy”. The “Design” and “Test” introduce huge variability in the process that does not exist in a manufacturing Kanban system. The work to be done is not known in advance. This means that it is not possible to know in advance when a customer request can be satisfied. This means that there is a real danger than customer demand floods the software development process leading to huge levels of work in progress that takes a long time to deliver.

Kanban in Software addresses this problem by limiting work in progress. It does this at a system level and/or a workstation level. To match supply and demand, software Kanban uses queues to identify where two workstations or systems are operating at mis-matched rates. A queue between two system/worstation grows when the up stream is faster than the down stream, and a queue shrinks when the up stream is slower than the down stream.

Software kanban can be implemented using explicit work in progress limits which specify the maximum number of work items in each work station and in each queue between work stations. Alternatively, a Kanban system can be operated using a work in progress limiting policy which also limits the amount of work in the system. ( e.g. Each person can only work on one item. Only one item is allowed in each queue ). These limits lead “idle” work stations that are blocked to help the other works stations that are blocking them.

Rather than specifying the date when software will be delivered to a customer, Kanban focuses on ensuring the order in which software will be delivered. Limiting work in progress ensure that the software is delivered in the fastest time, and reduces (but does not eliminate) the uncertainty around when it will be delivered.

Kanban Sucks (in Software)

In a manufacturing Kanban system, the kanban card moves from a down stream work station to an up stream work station to act a “Pull” / request.

In a software Kanban system, completing a work item or taking an item from a queue creates a “hole”, a gap of unused capacity at the work station, or a space in a queue. This “hole” or gap can then be filled.

Karl Scotland and Eric Willike coined the phrase “Kanban sucks!” which is a very profound and deep understanding of the differences between manufacturing kanban that “pulls” and software kanban that “sucks”.

Go to the Gemba

When you are master in one domain, it is very seductive to assume you are a master in another domain if they use similar language. Studying training software helps you understand how software companies sell their product. If you truly want to understand how kanban in software works, then you need to “go to the gemba” and see how practitioners actually do the work.