Learning agile while practicing. Programmer, husband, father. Cyclist wannabe. I try to be the best
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.
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 , 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.
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?
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.
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:
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).
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 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 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.
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.
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).
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:
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.
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.
 Ohno, Taiichi (June 1988). Toyota Production System — beyond large-scale production. Productivity Press. pp. 25–28. ISBN 0–915299–14–3.
Create your free account to unlock your custom reading experience.