I recently ran an 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. Introduction to Kanban 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 (JIT) by using customers demands to control the supply chain. just-in-time-manufacturing 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 . It achieves this by a five steps simple algorithm: throughput by eradicating limiting factors 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 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 . flow improve our throughput From this point of view, both Kanban and TOC have the same (not punt intended here). goal 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 , 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. on a system constraint Kanban focuses on managing flow by limiting WIP and managing queues Kanban focuses looking for bottlenecks where the flow is constraint by a particular sub-process or blocker. There is less and more on use of to highlight the bottlenecks. Queues are used to manage the flow. on managing the flow, emphasis on hunting down constraints visual signals Buffers, queues Buffers are used throughout TOC, typically as a result of the exploiting and subordinating steps (steps 2 and 3). Buffers are placed before the identified constraint, assuring that the constraint is never starved. explicitly 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.

Flow

Chain

Decisions

How do you estimate for teams with different development speeds?

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Kanban or TOC, which came first?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

A mechanism for building a roadmap

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

A mechanism for building a roadmap

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

10 Product Development Traps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps