I get asked often, "Where do you start?" Where do you start, if you want to make improvements and follow the ideas in the Theory of Constraints, when you don't know where the constraint is, or how to identify it?

The answer is pretty simple. If you have no worthwhile measurements and no real insight to your software development group's productivity and performance, you simply drum at the rate of the output. As a batch of customer valued deliverables appear at the output, you allow a similar sized batch in at the input. This works regardless of your unit of value measure. It could be change requests (like the XIT SE example), or scenarios, or use cases, or features, or user stories, or function points or whatever you choose as a unit of value measurement.

What happens next? The constraint reveals itself! Parts of the system that truly have slack capacity will reveal themselves too, while the constraint will remain fully loaded. Because the input to the system is regulated at the rate of production of the system as a whole, and that rate is regulated by the rate of the constraint (even when it is hidden or unknown) then the system stabilizes. This stabilization provides the base platform on which policies can be changed (subordination decisions) in order to fully exploit the constraint. Subordination decisions may utilize slack capacity elsewhere in the system to help fully exploit the capacity of the constraint. The XIT SE example showed this with injection #3 that moved slack testing capacity into development (the CCR). Making these changes (subordination decisions) is what causes improvement to begin and sets the organization on a journey of continuous improvement.

Once the constraint is revealed, the drumming can be triggered off the constraint itself rather than the output of the system.