Theory of constraints in Agile
Constraints – your weakest link
A concept from Management Theory called “theory of constraints” has become popular in Agile and Lean circles. The theory is quite simple, and relates to the constraints or bottlenecks in any process (manufacturing or knowledge work). This article will explain the theory of constraints and how it relates to agile software development, in a micro and macro context.
What is the Theory of Constraints?
The Theory of Constraints principles were developed by an Israeli thinker named Eli Goldratt, in the 1980s. It is was popularised by his excellent book “The Goal” (which I highly recommend – it is seen as a classic work in Lean Thinking), and was a major influence on the more recent famous book “The Phoenix Project“, a classic book in the agile and DevOps community.
The theory itself goes like this. In any given system, there will be one component that is the constraint or bottleneck for the system, in terms of restricting the output of that system. Any attempt to optimize any part of the system other than the constraint is a waste of effort, since it will not improve the throughput of the system.
All efforts of the organization should go towards improving the constraint. This should continue until it is no longer a constraint. At this point, the next weakest part of the chain becomes the constraint, which should be optimized.
The Five Focusing Steps of the Theory of Constraints
These steps are more formally described as the Five Focusing Steps:
Identify: Look to identify the current system constraint, i.e. the one part of the process that limits the rate at which the system-optimizing goal is achieved.
Exploit: Go and make some quick improvements to the throughput of that constraint, using any available resources (even if those resources are currently engaged).
Subordinate: Look at all other parts of the process to ensure that they are aligned with and really support the needs of the constraint
Elevate: If the constraint still exists (i.e. it is still the overall bottleneck to improving the system-optimising goal), consider what further actions can be taken to eliminate it from being the constraint. The above actions are continued until the constraint has been “broken”, i.e. it is no longer the constraint, and some other part of the system has become the constraint. In some cases, capital investment may be required.
Repeat The Five Focusing Steps are a continuous improvement process. Therefore, once a constraint is resolved and no longer the constraint, the next part of the system that has become the constraint should be addressed, following the previous steps.
This final step is a reminder to never become satisfied. Every system has as constraint, otherwise the system would produce infinite output. So keep addressing constraints!
Applications of the Theory of Constraints
This sensible idea became popular in management circles with the publication of Eli Goldratt’s Theory of Constraints book “The Goal” in 1984. The application in Lean and Agile circles is usually at a what I consider a “micro” level. I mean by doing things like implementing WIP (Work In Progress) limits on a VMB / Kanban board. WIP limits are actually an old Kanban concept and was developed independently from the Theory of Constraints.
There are some other uses for the Theory of Constraints, however.
One is Key Man Risk. A constraint is not necessarily a system, component or process. It could be a person. If there is one particular person that plays a crucial role in a process, work cannot progress through the system faster than that person can process the work. There is also the threat of complete disruption to the system if that person leaves or moves. Be very wary of the “one person around here that knows everything and we always go to when we really need to get things done”. That person is not a hero, they are a liability.
Another constraint could be a team or process that can block work. Common examples of this are a team that needs to verify or sign off work: release management, or business verification, or security testing are common examples. These teams and processes can restrict the flow of work.
The best solution is to make teams fully cross-functional “product teams” or “feature teams”, able to do all the work required to get software into production.
I talked a lot more about this in my article on cross-functional teams in agile.
Theory of constraints in Agile at a macro level
Another implication of the Theory of Constraints is at a much larger level. Many organisations adopting agile find that IT adopts quickly, but “the business” are much slower to follow. Strangely, most coaching and uplifting activities during an agile adoption are focused on further improving and optimizing the agility of IT, instead of business capabilities.
This is in violation of the theory of constraints. Improve the part of your organisation most in need of improvement. This could be your portfolio planning process, your change management process, your marketing and communications process, or something else.
Obviously, there is no point improving the efficiency of your IT delivery capability by 10% if it takes six months to get a business case approved and to get work to them. Improve the biggest constraint first!
Theory of constraints at a business level
There is an even higher level at which you can apply the Theory of Constraints. And that is business metrics. The XSCALE pattern language recommends constantly analysing your business through the lens of “Pirate Metrics“: Acquisition, Activation, Retention, Revenue, Referral. One of these at any given point in time will be your organisation’s bottleneck. Maybe you haven’t activated any customers. Maybe nobody’s heard of you. Maybe you’ve got a million leads but no sales. Maybe you’re selling but everyone gets jack of your product and drops it after a month. The metric that is your bottleneck can and will change over time. You need to measure this not once, but constantly.
You need to focus on the one metric that is your bottleneck, and fix it. Until it no longer is, and another metric is. Then the process begins again. Continually identifying, exploiting and attacking bottlenecks will maximise throughput over time and is the fastest way to achieving exponential growth.
