Tom's Ten Data Tips - August 2011

Theory of Constraints

The Theory of Constraints (ToC) emerged after widespread adoption of Lean manufacturing. It is a model that gets used to manage productivity. As such, it fits in very nicely with Lean, and focuses on (continuous) system level improvement by identifying and alleviating the bottleneck in throughput. You round up as many resources as needed to focus improvement at the system’s blockage. The rationale for this is that throughput of the system as a whole is determined by throughput at the bottleneck.

1. ToC Can Be Applied To Both Physical And Knowledge Work Alike

Although the ToC was originally developed for manufacturing, it turned out that the exact same principles can also be applied to knowledge work and project management as well. Just like Lean was initially mainly used for manufacturing, ToC initially was mostly applied for settings where physical products were manufactured. But software development and business intelligence can benefit from ToC as well.

For knowledge workers, the equivalent to inventory then would be work in progress, for instance. Throughput can be substituted by velocity in a Scrum team, etc. After you have identified your bottleneck (which isn’t always obvious!), the entire team should come to its aid. In software development we call this joint resolving of problems (alleviating the “bottleneck”) “swarming.” That way you maximize productivity for the team as a whole.

2. ToC Is Driven By Three Parameters: Throughput, Inventory, And Operational Expense

One of the eye-openers that many people get when they “see” how ToC works is that you cannot drive a system forward (system as in “systems thinking”) by pushing on only one objective. You always need to tackle more than one parameter at once, and keep an eye out for all three. The three parameters that are used in ToC are Throughput (the rate at which the system generates money through sales), Inventory (all the money invested in purchasing things that are meant to sell), and Operational Expense (all the money that the system spends to turn inventory into throughput).

Every improvement needs to take effects on all three of these parameters into account. Otherwise it’s not a net improvement. If you improve throughput and keep operational expense constant, what is happening to inventory? Usually it will need to grow, if even a little bit, to cope with fluctuations in throughput that are likely to occur at a higher frequency now, and maybe even with higher amplitude. Is the supposed productivity improvement worth the carrying cost of higher inventory? Otherwise the system has not improved. Etc.

3. After “Fixing” Your Bottleneck, A New One Will Emerge

At the core of ToC is the insight that the system’s output is determined, and can never be higher than the throughput that passes the bottleneck. The next step is then called “lifting” the bottleneck, which begins by identifying, and then maximizing the bottleneck.

If integration testing happens to be your bottleneck, make sure that people who do this work do not get assigned any outside duties. You can also enhance (net) throughput there by ensuring that only features that will get accepted require testing, which often means looking more careful at requirements. If a feature gets rejected in acceptance testing, then you have not only wasted the entire production chain, but more importantly you have wasted a unit in integration testing that could have been prevented upstream (during requirements gathering).

But even when you manage to fully exploit integration testing, and after you expand capacity by hiring more staff, then perforce somewhere in the system a new bottleneck will emerge. Rinse and repeat: look for the new bottleneck, leverage its full capacity, maybe expand capacity, and go on to find the new bottleneck.

4. ToC Requires Throughput Accounting Instead Of Cost Accounting

One of the important insights from ToC is that traditional cost accounting does not always steer organizations towards their most “optimal” state. More specifically, cost accounting focuses on the effort expended (Operating Expense, OE) in the system, whereas throughput accounting focuses on what that system is there for: to generate products (Throughput). This distinction explains why cost accounting sometimes drives towards locally optimum solutions that actually harm throughput and profitability.

In order to make ToC “work”, you need ‘the right’ numbers to operate on. Sometimes cost accounting can suggest phony ‘improvements’ that actually drive Throughput down. In cost accounting, for instance, work in progress (WIP) increases in value as it moves through the system. In throughput accounting WIP is a liability, because it isn’t until it gets accepted that you know whether it needs to be written of (turned out to be a misfit), or whether it created value. So throughput accounting will ‘drive’ inventory down (which improves efficiency in the system), whereas cost accounting ‘attempts’ to lower OE, e.g. lower the number of worked hours per item, even if inventory goes up along with it. This makes a big difference, and would lead management to take fundamentally different decisions. Cost accounting might lead to full warehouses (assets!) with no buyer in sight…

5. “Common Sense” Doesn’t Always Make Sense

One of the most insightful findings in ToC is that often the very efforts that are meant to improve throughput can sometimes have the exact opposite effect. You need a “systems thinking” approach to appreciate sometimes counter intuitive behavior in a production chain. For instance, it is not a good idea to always have all the people “busy” or even working. You must have slack, or idle time, in order to have an efficient system.

The reason why idle time, or “slack” is (always!) needed is to cope with inevitable variations in throughput. The more “tight” everybody is scheduled, the more these tiny ripples in flow will cause throughput to come to a halt. And when the flow of work happens to interrupt your bottleneck, this will adversely affect system throughput (output of sellable product). Sequential dependencies make a system’s behavior difficult to predict, and susceptible to interruptions in workflow.

6. Expediting ‘Kills’ Natural flow

When some product, either a manufacturing product or a specific software release, or a “hot” bug fix needs to get delivered as soon as possible, we resort to expediting. “Expediting” here means treating this work object with the highest priority, even when this means slowing or stopping other work.

Expediting has more or less the same kind of effect as an ambulance or police car passing by at high speed. All the other cars need to move over to the side, to make room for the ambulance to pass. The ambulance gets there faster than “normal” traffic would allow, but all the other cars have to wait. For them, the journey will now take (considerably) longer. No just the delay for getting out of the way, but also the additional delay because the flow of traffic was interrupted and needs to settle into a flow again.

7. Kanban Is A Natural Extension Of ToC

Kanban, or so-called “pull-systems” are a natural extension of both Lean and ToC. Kanban is a system where work does not get “pulled” into the workflow until production capacity ‘allows’ this. These limits on work-in-progress are a cornerstone in Kanban to improve system efficiency and predictability of delivery times.

The introduction of Kanban helps to focus on smoothing the flow. Both ToC and Kanban aim to improve the flow of work. For this reason, you set separate policies and standards for different “classes” of work in Kanban. For instance: two classes of “expedited” versus “normal” delivery of throughput. But there can be more than two classes, if this is deemed desirable. Each have their own work policies and SLA’s.

8. SPC Is A Crucial Ingredient In ToC

Statistical Process Control (SPC) plays a key role in making the Theory of Constraints work properly. It was pioneered by Walter Shewhart and later popularized by Deming. By gathering data along the manufacturing chain, empirical process control is enforced. This is a cornerstone in Scrum as well.

For unpredictable development (like software) it is an illusion that you could predict the entire process upfront (see also tip# 9). This is why Agile developers vehemently resist the Big Design Up Front (BDUF). So instead we apply SPC to observe the actual flow of production, and set work policies accordingly. These SPC data might have a different content for manufacturing and software development, but the metrics are highly comparable.

Whenever you have sequential dependencies, like work that needs to be completed in a fixed order, any (small) variation will ripple through the chain, and therefore needs to be contained. Bottlenecks need to be “protected” by commensurate buffers of completed work in front (upstream) of them, despite the fact that these negatively impact efficiency because they cause inventory (Work-In-Progress) to grow. This, of course, is a balancing act. The size of these bottlenecks needs to be calculated on the basis of historical fluctuations, hence SPC.

In software development the SDLC model (“Waterfall”) assumes scope-budget-schedule and therefore puts a lot of emphasis on initial planning to get the scope of a project “just right.” This is why they are considered “heavyweight” methods: they require a lot of design and specification documentation.

In Agile methods we assume schedule-budget-scope, which is why it’s so important to monitor progress with SPC. In Agile planning we “predict” deliveries by extrapolating historical delivery, and extending these trends out into the future. In order to give empirical ranges (rather than point estimates), you apply SPC to give a statistically sound upper and lower bound for either the number of features available at a certain date, or a timeline within which work shall be completed with accompanying probabilities. E.g.: there’s a 90% probability that work will be completed within 14-21 weeks from today.

10. ToC Drives For Different Goals

Probably the most important contribution of ToC is a reorientation on what metrics truly drive a business forward. Although cost accounting may still be required for GAAP reporting, it provides suboptimal, and sometimes downright misleading numbers to monitor the well being of your business. “Metrics should ideally be self-generating and should provide leading or predictive indication of the system performance rather than lagging or reactive performance” (Reinertsen, 1997).

Traditional metrics focus on minimizing Operating Expense, which emphatically does not maximize profit, or ROI. This is why they are misleading, and can lead companies astray. Instead, the early and speedy delivery of functionality to end-users needs to be maximized while keeping Inventory and Operating Expense in check. Shorter cycle (iteration) times lower Inventory, which is a cost. And lower Operating Expense implies you are spending less money turning an “idea” into requirements, features, and eventually a user-accepted solution. That, is our goal, and should ultimately drive the system.

Further reading

Some excellent books on the Theory of Constraints:

The Goal, 2nd Revised Edition.
Eliyahu Goldratt (1992)
ISBN# 0884270610

Managing the Design Factory: A Product Developer’s Toolkit.
Donald Reinertsen (1997)
ISBN# 0684839911

The Principles of Product Development Flow: Second Generation Lean Product Development.
Donald Reinertsen (2009)
ISBN# 1935401009

Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results.
David Anderson (2003)
ISBN# 0131424602