Paul Hammant's Blog: The iron triangle is actually a square and not particularly iron

The Iron Triangle

Remember this (figure 1)? - You remember, quality is a function of scope (how much functionality to build), resources (how many people assigned to it), and schedule (how long to take). Schedule and resources conspire together to make a dollar - right ?

Classically, people put the legends on the vertexes and not the edges, but I think it better the way I have it. The visuals feel comfortable - right? If we reduce resources & constrain the other two and you get a reduced quality (figure 2) - right?. Maybe, but we really shouldn’t put too much stock in this particular iron triangle. Principally because quality is a actually thing you can specify too. You can assign resources to manually testing software (or not). You can assign resources to write automated tests (or not). Both of those are sliding scales - refer to the test pyramid, seeing as we’re obsessing about shapes today.

Second class thinking

Thinking of quality as a consequence of scope, resources and schedule is second-class thinking. If we believe that quality should be a choice not a consequence, then it is a square trapezoid, and not particularly “iron”:

Feels precarious - right? Could be be an iron rhombus with a little nudge, before it falls flat.

Scope should be set free

Successful Agile teams have long since learned that it is still a triangle (shhh), but it is scope that should un-constrained (or resulting), and quality that you constrain/specify :

You measure the projects success by looking at the scope completed at the end. Or per release, milestone or even iteration. We’re touching on lean now, with a throughput-like thing we’re trying to optimize for.

Vendor Contracts

Contracts written with vendors around quality, resource and schedule are “Time and Materials” types. You still get to be disgruntled with the vendor, if there’s not enough completed at the end of the schedule (or you’re predicting part way through that will be likely). There is a traditional reaction to a project falling behind - a suggestion to cut quality (how sad). Either way, at the end of the contract you work out if it is time to change vendors. That implies that you have participants that are not as skilled/experienced enough with the technologies as you expected. It could be that you’ve chosen the wrong technologies too, or the non-functional requirements are odious. I wrote about that too - Average Story Sizes of One Day.

Others on this topic

Scott Ambler has previously written a different Broken Iron Triangle commentary on the iron triangle. Max Pool followed up with The Broken Iron Triangle Is Broken. Jurgen Appelo got the square concept too in a Getting Square article.