The Lie of the Iron Triangle
By: Dan Ray
Tags: Process Improvement, Scrum, Software Development, Serious Scrum, Agile

In my pre-Agile career, I often had that experience of a project getting scoped, planned, budgeted, quoted, sold, and scheduled — and then almost immediately going off the rails. A late-breaking requirement or sudden new scheduling demand can turn the best laid plans of PMs and Managers into nonsense almost immediately.

Or even if that doesn’t happen, the natural course of development causes complexities to surface that couldn’t have been foreseen during planning. No amount of good intentions or hard work ever seemed to save us; we always ended up having to explain to the customer why they weren’t going to get what they paid for on the schedule we promised. ALWAYS a fun conversation.

Looking back over the waterfall phase of my career, this seemed to happen much more often than it didn’t. I can only think of two or three projects that actually went according to the plan we laid out at the kickoff meeting. And yet we kept doing it the same way, over and over! Could anything be more insane?

So you can imagine my joy when I was introduced to The Iron Triangle.

Also known as the Project Triangle or The Triple Constraint, the Iron Triangle is an attempt to convey in a simple way the interrelatedness of the aspects that impact project delivery.

The three sides of the triangle are: Scope, Budget, and Time.

How triangles works is, they’re connected at their three corners. You can change any one of the sides, but at least one of the others has to change too, if you’re going to keep it a triangle.

“If you break the Triangle”, it is said, “quality leaks out”. (More on THAT later.)

The value of this diagram is, it’s easy to communicate the idea that if you increase Scope, you either need to add Budget (usually in terms of team head-count) or Time. If you decrease Budget without changing Time, you’ll need to decrease Scope. Et cetera.

A change in scope requires a change in time or budget

This is a pretty nifty expression of the interrelatedness of some project delivery factors. And let me tell you, whipping this sucker out on the whiteboard when a customer is asking for a new feature they just came up with has provided some of the most grimly satisfying moments of my career.

This is a very powerful tool for waterfall Project Managers to shut down customer collaboration. We call it “defending the scope”, but it’s really about valuing a signed piece of paper over working together with actual human people.

The thing that I never understood until I started working in a new way is that there’s actually a fourth side to the Iron Triangle. That’s what makes the whole thing a lie. Who ever heard of a four-sided triangle!?

Consider this: How many of us working waterfall projects have gotten stuck with immovable requirements, impossible timelines, AND inflexible budgets, all at the same time? When it just can’t all work, what do you do? How do you deliver?

The answer for me and many others I know is, you dial back quality. You might not call it that, of course. You “compress your testing time” (i.e. you skimp on QA). You “downgrade the severity” of as many defects as you can (i.e. ignore them), and you ship. You might also compress your rollout plan, cutting down time for training, or bringing users on board faster than is safe, which is a compromise of implementation quality.

The classic Iron Triangle says that quality suffers if any of the three sides are moved independently, but I can personally vouch that poor quality also results from refusing to move any of the three sides in the face of a project’s inevitable change.

Quality doesn’t “leak out” if you break the triangle. Quality is the invisible “fourth side” of the triangle that is often quietly “changed” in an attempt to satisfy the other three constraints.

And of course poor quality has real costs in maintenance, user satisfaction, and certainly in value delivered to the customer. Inevitably as quality standards drop and technical debt increases, delivery time stretches and costs inflate.

Thankfully, Scrum saves us from all of this. We can set down the Iron Triangle and back away slowly!

In Scrum, quality is fixed. It’s defined in the Definition of “Done”, and that’s that.

In Scrum, budget is fixed. A scrum team is stable and cross-functional, containing all skillsets needed to deliver “done” work.

Time in Scrum is not fixed. Time to a release is an unknown but hopefully small multiple of short, fixed-length sprints. We don’t pretend we can see the future all the way to a deployment date; we know empirically that we can’t. (If you need evidence of that, I have stories I can tell you.)

Now it can be argued that Scrum IS time-fixed. After all, we know how long every sprint is, and we know that every sprint is going to produce a potentially shippable increment. True! But the key word is “potentially”. Just because every increment could be deployed doesn’t mean they all will. The number of sprints we are away from a release is unknowable in advance, and depends on lots of factors, some of which aren’t in the team’s control. We make this scheduling uncertainty palatable to the Customer by having every increment deliver them value, even if that value doesn’t get all the way into the hands of users.

But the most important thing that’s not fixed in Scrum is Scope. It can change from day to day, right there during a sprint, as business needs and market conditions change. Scope is very much open to adaptation as we learn more in the course of development, or as we vet the product with stakeholders and customers. In Scrum, we don’t pretend we can see the future, even as far as the end of this sprint! Embracing that flexibility leaves us better off through development, and certainly leaves us with a better product in the end.

Crucially, the concept “How long until it’s finished?” needs to be airlifted out of your thinking if you’re going to be agile. “How long” asks an unknowable question about time. And what does “finished” even mean, if you haven’t banged some ideas against the marketplace along the way? (But notice how non-empirical our thinking is in waterfall, that we think this is the single most important question to ask? How much of our approach is based on assumptions, mythology, compliance to authority, and the sheer denial of what our track record is telling us?)

Try on the idea that “finished” isn’t a thing, and never really was. Instead of grinding toward some ever-receding finish line, release something unfinished and tiny! See what happens! Make your next tiny plan from there!

Before long you’ll have a sense of how your tiny versions are trending, which will leave you planning based on actually knowing something, rather than working from a well intentioned but doomed best guess. And you’ll find that the protection that the Iron Triangle is designed to provide just isn’t needed anymore.