I recently ran an Introduction to Kanban training session for my work colleagues. I have started with Kanban origins, talking about how Toyota started studying supermarkets and customers shopping behaviour in supermarkets.
They observed that customers generally purchased what they needed, when they needed it, knowing that the future supply was assured. Conversely, supermarkets stocked up on only what was expected to sell.
In a hope to improve their manufacturing processes, Toyota’s desire was to apply the shelf stocking techniques to their manufacturing floors.
I’ve continued by explaining how they applied the technique to achieve just-in-time-manufacturing (JIT) by using customers demands to control the supply chain.
Demand from the end customer passes up through the supply chain. Kanban uses this rate of demand to control the rate of production. Goods are produced only when needed.
Simplistically, the process works as follows.
Distribution pulls an item from Manufacturing. As it gets pulled, a card from a Kanban table is attached to the item.
Consumption pulls an item from Distribution. The previously attached card is removed from the item and returned to the Kanban table.
A manufacturing request is triggered when the Kaban table fills up to a ‘red redline’.
At this point, one of my colleagues asked me: you are explaining something very similar to Goldratt’s Theory of Constraints (TOC), you are describing a process that tries to identify production bottlenecks. Which came first, Kanban or TOC?
“Hm, Kanban first, I think”, I’ve answered. I thought a bit more, and said “yes, definitely Kanban first”.
Then came the subsequent question: is TOC the same as Kanban?.
“Hm, no, but you can use TOC in Kanban” I said. Then I’ve moved on. After-all, I thought that I was only on slide 12 of 65 and time was marching on. After the session I felt though that these were some really interesting questions which deserved a better explanation; I should have elaborated more. This write-up is my attempt to address these questions better.
So, which came first, Kanban or TOC? This is an easy answer, definitely Kanban. In 1953 Toyota applied this method in their main plant machine shop [1], decades before Eliyahu M. Goldratt introduced the Theory of Constraints in his book titled ‘The Goal’ (1984).
What about the second question, is TOC the same as Kanban? The answer is no, but this answer is worth elaborating a bit.
Synergies
How did my colleague made an association between the two concepts? If they are not the same, why do they feel similar? What are the synergies between Kanban and TOC?
Shared roots
Both concepts have their origins in manufacturing. Goldratt used a manufacturing plant to introduce the TOC concept in his book; Kanban was originally created to improve the manufacturing processes at Toyota.
Improving throughput
TOC is a concept that can be applied to a process or system to improve the throughput by eradicating limiting factors. It achieves this by a five steps simple algorithm:
- Identify the system’s constraint(s)
- Decide how to exploit the system’s constraint(s)
- Subordinate everything else to the above decision(s)
- Elevate the system’s constraint(s)
- If in any of the above steps the constraint has shifted, go back to Step 1
Kanban is first and foremost a work in progress limiting (WIP) method, with its original aim to achieve just-in-time (JIT) manufacturing by eliminating the superfluous inventory.
The adaptation of Kanban to software talks about improving the flow of value to customers, where value is typically expressed as Features of a product or a service being built or enhanced. If I were to simplify this statement a bit, I’d say that we use Kanban as a work method to improve the predictability of a process, one that helps us to improve our throughput.
From this point of view, both Kanban and TOC have the same goal (not punt intended here).
Hunting for bottlenecks
While both concepts share an ultimate goal of improving the throughput of a process, they are going about achieving it in a slightly different way.
TOC focuses on a system constraint, the most important limiting factor(s) that stands in the way of achieving the goal, and then improving the constraint until it is no longer a constraint (in the book this was the most heavily loaded machine). Once the constraint is found then the entire system is subordinated to best exploit it. The constraint is often referred to as a bottleneck and buffers are used to manage those bottlenecks.
Kanban focuses on managing flow by limiting WIP and managing queues
Kanban focuses on managing the flow, looking for bottlenecks where the flow is constraint by a particular sub-process or blocker. There is less emphasis on hunting down constraints and more on use of visual signals to highlight the bottlenecks. Queues are used to manage the flow.
Buffers, queues
Buffers are used throughout TOC, typically as a result of the exploiting and subordinating steps (steps 2 and 3). Buffers are placed explicitly before the identified constraint, assuring that the constraint is never starved.
Buffers are placed explicitly before a system constraint, assuring that it never runs out of work. If a constraint runs out of work then it has an even bigger negative impact on the throughput of the entire system.
Kanban doesn’t use the concept of buffers, instead it uses the concept of queues. It looks at the queues as a way to signal that there is either too little or too much work in front of a later activity. Kanban tends to limit the size of the queues by using WIP limiters. A minimum WIP is a buffer in sense of TOC (we are imposing a minimum number of items in front of a phase of work); a maximum WIP it is not.
A queue between two activities on a Kanban board. An empty queue before ‘Review’ activity could be a sign that we are at risk of starving the ‘Review’ phase of work. Conversely, a large number of items piled up in a queue can indicate bottlenecks in the downstream activities.
TOC in Kanban
Kanban uses the concept of queues and WIP limiters, but offers no formula of how to set the size of these WIP limiters.
One way of setting the WIP limiters is by using TOC concepts. You can measure your system using flow metrics and identify the most constraint activity (step 1 in the TOC algorithm).
Activities in a Kanban system can be constrained
For instance, let’s assume that the most constraint activity is Test. In this case, as a first measure we want make sure that this activity is never starved of work, that there are always items to test (step 2 ); once we achieved this, we could work subsequently on increasing the testing capacity (step 4).
To assure that Test is never starved of work, we can do few things, such as:
- set a minimum queue size in front of the Test phase, assuring that there is always work ready for the Test team
- set a WIP limiter for development smaller than the number of the available developers so that should any items get blocked in the Test phase (let’s say due to identified defects) developers can react quickly to remove the blocker. We want to fix the issues as soon as possible because we don’t want to have a situation where the most constrained phase gets blocked, exacerbating its limitation and increasing the negative impact on throughput even more.
To increase the capacity of testing we would need to identify first what are the limiting factors of the testing phase: is it the number of test team-members, is it the type of work they do (i.e. maybe too much manual testing), is it the lack of environments, etc? Once we have identified the cause(s) we can work to eliminate them.
As defined in TOC, we would need to continuously monitor if the constraints are shifting, if they are moving to other phases of work.
Conclusions
With roots in manufacturing, Kanban and TOC have not been created for the same purpose. Kanban was created to achieve JIT manufacturing and to manage flow. TOC is a concept for process improvement by focusing on constraints.
One is a method, the other is a management paradigm, therefore comparison is difficult because we are not comparing apples with apples, however, the synergies between the two are strong.
How to use them? Combine them. Use Kanban to define the working method and use TOC to optimise it, to polish it.
[1] Ohno, Taiichi (June 1988). Toyota Production System — beyond large-scale production. Productivity Press. pp. 25–28. ISBN 0–915299–14–3.