An agile view of the classic triple constraint
For decades project managers have learned about the “Iron Triangle” or “Triple Constraint.” Let’s explore how this operates in an agile ecosystem.
Traditional Triple Constraint
Traditional development locks the “Scope” and “Time” side of the triple constraint and varies the cost side of the triangle. This is usually done by approving a business case effectively requesting a certain scope is done by a certain time and then funding the right number of team members to do that work.
Agile Triple Constraint
The triple constraint still applies in an agile ecosystem it just “locks” different sides of the triangle. In an agile ecosystem there is an acknowledgement that the full scope of work is unknown, it’s possible the direction may change increasing or decreasing scope as the work is executed so that side of the triangle is flexible. Time is usually fixed, something is always done by sometime. Typically work is delivered via fixed iterations, sprint by sprint as well as larger batches in some scaling methodologies like Program Increments if you’re executing SAFe. As a result agile execution is typically funded for a set duration. In addition agile execution locks the cost side of the triangle. It’s recognized that you can’t easily spin up and spin down teams so these tend to remain constant and are funded for a longer duration. The net result is that in an agile ecosystem an annual budget is for a certain number of teams over a certain time period (typically a year). There is a general value proposition to support funding those teams but it’s acknowledged up front the plans are just forecasts and can change quickly based on new information acquired during execution.