Once you eliminate your number one problem, number two gets a promotion. - Gerald Weinberg, Consultant and author of The Secrets of Consulting
The Theory of Constraints says that every system is limited by one or two constraints at a time. Once you alleviate the constraint, the system will improve.
For example, in a company where an inexperienced development team was recently hired to fulfill a technical need, the capacity of the system might be limited by the developers ability to launch new features. The development team has yet to find a way to work together and crank out features at a steady pace. Once the development team has improved with proper guidance, and going at full speed, the constraint of the system shifts elsewhere: such as the product owner who might have a hard time deciding features for the team to implement, leading to a waste of programming time. And again, once this constraint is alleviated, the system will be limited elsewhere, and so on.
To continually improve a system, Eliyahu Goldratt in The Goal: A Process of Ongoing Improvement proposes a five-steps process:
Examine the system and find the limiting factor (the constraint).
Ensure the resources related to the constraint aren't wasted. In the example above where the development team's implementation speed was the limiting factor, you could make sure the time of the team is not wasted in other activities, such as technical support, unnecessary meetings, etc.
Redesign the entire system to support the constraint. In other words, redirect resources to the limiting factor, even if other parts of the system lose access to them.
Permanently increase the capacity of the constraint. In the development team example, this would mean hiring more programmers. In software, particularly, adding more programmers doesn't always result in faster development speeds, but given the time and resources needed to grow a development team properly, this alternative certainly works in the long run. Elevation usually has a high cost, which is why Exploitation and Subordination come first.
After making changes, reevaluate the system to see where the constraint is located. If the constraint shifted elsewhere, repeat the steps to improve this part of the system.