A concept from Management Theory called “theory of constraints” has become popular in Agile and Lean circles. The theory is quite simple. This article will explain the theory of constraints in Agile, in a micro and macro context.
In any given system, there will be one component that is the constraint or bottleneck for the system. Any attempt to optimise 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 organisation 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 optimised.
This sensible idea became popular in management circles with the publication of Eli Goldratt’s 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 constaint 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.
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 optimising the agility of IT, instead of business units.
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.
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.