Theory of Constraints

The Theory of Constraints is a system improvement tool. It illustrates how in a system where we find a bottleneck, the bottleneck is the constraint that limits the performance of the entire system.

For example, on a software development team that has a number of software developers and only one tester, the work will quickly pile up in front of the tester. The speed at which the tester operates constrains the whole team’s ability to deliver value. Non-software example: we have a team with several writers and only one editor. The pile of work that needs to be edited quickly grows. The editor (like the tester) has become the bottleneck to delivering value.

No amount of speeding up work at the other stages will affect the throughput of the team. So I would expect these teams to put in effort to reduce the pile of work in front of the bottleneck. In this case, that would likely involve cross-skilling. Could a writer do a first editing pass on another writer’s work? Can a developer help with testing? Over time, an Agile team would expect that multiple team members will learn in areas where the team experiences bottlenecks, so they can handle this naturally and within the team itself.

The full theory of constraints has a number of steps to ensure the bottleneck is addressed. But to keep my examples simple, I just assumed the bottleneck was that the team had insufficient skill to help. Done well, the analysis would have been deeper and far reaching.

Theory of constraints comes to Agile from the world of manufacturing. It is the work of Eli Goldratt, explained in the business novel The Goal.