Theory of Constraints, Lean, and Agile Software Development


and introduced to the world in the business novel "The Goal" [4] simply asserts that there is only one bottleneck in a system of production. Throughput of the overall system will always be limited by that bottleneck. The idea is that if you want to increase the overall throughput of the system you need to focus almost exclusively on improving the performance of the bottleneck (also known as the quot;constraint,quot; thus the quot;Theoryquot; of Constraints). Efforts spent elsewhere are waste (in Lean terms) and could even be counterproductive.

So what does ToC advise we do? We should:

  1. Find the bottleneck (the slowest point in the system).
  2. Exploit and protect the bottleneck so that it does not get interrupted. Protecting the bottleneck is usually done with inventory, so if a step upstream of the bottleneck goes down, the bottleneck can continue to function.
  3. Make all other steps in the process subservient to the bottleneck#39;s capacity - in English, "slow them down"; and prioritize any work that affects the bottleneck.
  4. Elevate/improve the capacity of the bottleneck until it is no longer the slowest step in the system.
  5. Go to step 1 and continue.

In Figure 1, the bottleneck is step D running at a speed of 30. We would keep the inventory between C and D, slow all steps to a speed of 30 (thus removing all other inventory), and use the resources to make D go faster until it is no longer the slowest step in the system.

For this to work, the bottleneck must be a global bottleneck (for the entire system) and not a local one (for a single step in the system). Otherwise, addressing a local bottleneck will make a non-bottleneck step faster and will be effort down-the-drain because the real bottleneck has not been addressed. In our example, let's assume that the group responsible for step C have their own internal process and they work on making this nested process better. They will find a bottleneck for step C and remove it and therefore step C will increase to a speed greater than 60. This is great for step C, but actually does nothing to improve the system as a whole. In fact, it will probably result in increased inventory waiting to be processed between steps C and D.

ToC is very specific of where to start: the BOTTLENECK. The location of that bottleneck differs from organization to organization, so you will have to find your own bottleneck. Fortunately, they are usually not that hard to find - one of the biggest indicators is a pile of inventory stacking up before the slowest step as it gradually gets farther and farther behind the rest of the system.Specifically, in software development, the "inventory" that piles up is composed of requirements waiting to be processed (this can be development, testing, integration, deployment, etc...). Typical bottlenecks include requirements specification (the rest of the system is starved for requirements because it takes so long to create requirements documents), system test/ QA, and defects (rework inventory). We find it interesting that actual coding work is commonly not the bottleneck, and yet it seems to receivea disproportionate amount of attention. Maybe coders are the biggest whiners?

What's interesting about this approach is that it is completely contrary to the notion of improving quot;personal productivityquot; or efficiency. ToC plainly states that not only is it ok but many times it's actually desirable for parts of your system to operate below their maximum capacity. To put this in terms of a software development team, let's say that UI QA has become your bottleneck, meaning that

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.