Ask any project manager if they’ve heard of the Iron Triangle, and the answer is, “Of course!” But if you’re part of an agile team, what do you need to know about the Iron Triangle and why?
The Iron Triangle brings together the following key constraints when it comes to planning a project:
The three constraints in your triangle corners determine the quality of the application or product that your team is tasked with building. In an ideal world, you’d have everything you want for $0, delivered yesterday, but reality isn’t so kind. It forces you to make choices. For instance:
- You might be able to deliver a project at the right cost (budget) and on time (schedule), but…
- To do so, you’ll have to sacrifice on scope.
- Your customer might have fixed features (scope) with an equally fixed release schedule (hello, Marketing!), but…
- To meet these constraints, you’ll want to start looking into augmented staff and high quality coffee beans for your engineering team (cost) to get you across the finish line on time.
To to put it another way: “Pick any two; you can’t have all three.” That’s how the Iron Triangle works.
But in the same way real-world projects aren’t as flexible as the Iron Triangle leads us to believe, the Iron Triangle looks even less like a triangle when it’s applied to custom software development projects delivered by agile teams.
Let’s walk through each element in the triangle and look at why:
- Budget - Clients never come with unlimited budgets (if they say they do, your very first ask should be for an espresso machine for the team!). Clients will always have some predetermined, finite budget that they can spend. Sometimes there may be a range and they can flex their spend, but the budget on a project invariably boils down to clients wanting to know how much bang they can get for their pre-defined bucks. And so, the Budget corner of the Triangle is pretty fixed.
- Schedule - Few of us have been on a project where the client puts together a budget and decides what you’re going to build but is completely okay with letting the team finish whenever. In other words, customers always have a deadline. It might be an arbitrary date or it might be a specific date—but there is always a date. And so, the Schedule corner of the Triangle is also fixed.
- Quality - Even though Quality sits in the middle of the triangle, the quality of your app or product is non-negotiable as well. Clients will never tell you that they want a project delivered on time… with bugs. Or that it’s okay to deploy a new release with half-baked features. Clients and users expect your app to work—and work well—or they’ll abandon your app. The user experience has to be clear. It can’t confuse, and it’d also be nice if it’s beautiful or at least impresses the user. I could list more examples, but in this way, Quality is also a fixed requirement in the Triangle.
This then leaves us with Scope. If the other constraints in the Iron Triangle are rigid and pretty much fixed, then the only area left where your project can possibly flex is scope.
The Iron Triangle isn’t a triangle at all. In reality, it looks more like a ring that flexes around your other project constraints:
From the client’s point of view, the question becomes:
Given the other project constraints, how much of what we want vs. what we need can we have?
Determining the right Scope requires that we take a hard look at the project:
- What features are absolutely critical for a Minimum Viable Product?
- What features or stories can be deferred until Phase 2 or later?
- Are there any user interactions that can wait until after the first release?
- Should we perform some usability and A/B testing to determine if we really want to build some features?
- Is there a set of features that must absolutely be delivered, in order to create the right experience for the user?
- What is the right experience? or the best experience?
- And so on…
Whenever you kick off a project, walking the team through the Iron Triangle with the client is a highly recommended exercise. The “triangle” nicely pulls together project constraints and our assumptions about them, and for the agile team that will actually be executing and delivering code, it’s an especially great tool to level-set expectations with the client.
Why? Because even with the best of teams, projects are highly likely to slow down or take a detour for any number of valid reasons. This is just the nature of software development projects and trying to estimate the future (but that’s one—or several—blog posts for another time ッ).
When that detour or a request from left field turns up, that’s when you can re-invoke the Iron Triangle and say, “We are where we are. Some change has come to our project, and we have to figure out how to absorb it. If we assume our original dates and the team are the same, then there’s only one area where we can flex.” And that’s where you can jump into a discussion about the most important part of the Iron Triangle: scope.