The body of knowledge referred to as the “Theory of Constraints” was originally conceived by Israeli business management educator and philosopher, Dr. Eliyahu M. Goldratt. Goldratt articulated the concept in his 1984 book The Goal: a fictional business novel which follows plant manager Alex on his journey to improving systems management within the factory where he works. Goldratt’s Theory of Constraints inspired the development of new business management concepts and systems to revolutionize production procedures in manufacturing. So, what the heck does all this have to do with DevOps you ask? At its grassroots, the principles of DevOps lie in Agile and Lean practices for improving deployment and manufacturing processes. These practices of systems management all seek to improve on or, where possible, remove bottlenecks through process analysis. Identifying and acknowledging such bottlenecks and constraints is not always easy though, since they may only slow work down rather than stopping it completely. This makes it difficult to analyze—or even see—the impact which resulting longer lead times can have on both internal and external customers.

What Is the Theory of Constraints?

Since The Goal’s publication, the Theory of Constraints has become a reputed model for eliminating waste, recognizing opportunities for better collaboration, and streamlining the flow of work down the value stream. And as the manufacturing value stream bears a striking resemblance to the technology value stream, it is entirely possible to apply the Theory of Constraints methodology to DevOps and see the same positive impact. The methodology seeks to identify any limiting factors that are standing in the way of a business process achieving its goal. Once identified, the aim is to systematically work and improve on such constraints until it is no longer a limiting factor. The Theory of Constraints is essentially about taking a scientific approach to improvement. Every complex system—which describes a deployment pipeline accurately—is formed of multiple linked actions designed to achieve an end goal. Hence, any constraints (weak links) within the system compromise the entire process. The conflict cloud within IT can be visualized as such:

Five Steps to Improving Your Development Pipeline

There are five focusing steps within the Theory of Constraints to help IT teams identify and eliminate bottlenecks within the technology value stream. The steps, as the diagram below represents, are cyclical in nature:

• Identify the constraint: Locate the weakest link in the system, this can be both physical or a policy rule.
• Exploit the constraint: Make fast improvements to the constraint productivity with existing resources.
• Subordinate everything else: Make the constraint your number one priority to gain maximum effectiveness. Everything else must take a back seat.
• Elevate the constraint: Take whatever action is necessary to eliminate the constraint. If all else has failed, make major changes to the existing system at this point.
• Repeat the process: Continuous iteration will help prevent complacency.

The Theory of Constraints in Software Development

The above steps are great for concentrating efforts on identifying and eliminating bottlenecks within a process. But how do we prevent constraints from occurring again in the future? Well, the Lean influences within the DevOps methodology actually provide a great defense strategy to follow on a daily basis. These practices will help prevent constraints working their way back into the development pipeline and having a negative impact on work in progress (WIP). These include:

• Reducing batch sizes (keep project work small)
• Decreasing WIP (restrict the number of projects in progress)
• Limiting the number of handoffs (shorten the number of steps work must take before deployment)
• Shortening and amplifying feedback loops (improve the flow of work down the value stream)

Just by following these DevOps/Lean practices with the Theory of Constraints methodology, IT teams will be able to see dramatic increases in productivity, output quality, as well as internal and external satisfaction. For a more detailed review of these concepts, check out the DevOps Handbook Series Part 1: The Three Ways.