The Myth of the Iron Triangle


I am always amazed at how often accepted truths turn out to be false.

I am further astounded at how liberating it is to throw off the constraints imposed by those beliefs. The first myth that Kent Beck, the father of Extreme Programming, shattered for me is that change does not have to be expensive. The cost of change can remain relatively flat throughout all phases of the development lifecycle by re-organizing and re-thinking how software is developed.

The second myth, which I am now ready to castoff, is the Iron Triangle.

The Iron Triangle (figure 1) influenced much of my career and decision making.

It defines the relationship between scope, resources, and time. I was taught that you could not get more of one without more of the other. Thus, if I wanted to add more scope to my release, I would have to add more resources, time, or both. I could also fix one and then try to optimize the other two. But the relationship between these three qualities was defined and rigid.

There was one backdoor. You could play with the sacred 4th dimension of the triangle – Quality (Yes, I recognize that this would then be a quadrilateral.). No one wanted to deliberately state that we would compromise quality, so it was seen as fixed. But this is where the model and reality often diverged. Projects often sacrificed quality to add more scope and/or deliver faster. Lowering quality was the one way to create an exception to the Iron Triangle.

Agile Product Management Iron Triangle

Figure 1: The Iron Triangle


But with test driven development in an Agile environment, teams do not defer defects. Quality is built in.

Because less time is spent fixing bugs, the team is more productive, time to release decreases, and more scope is completed (figure 2).

Teams transitioning to Agile describe this effect as going hyper-productive, where they enjoy throughput gains of 100% – 200%. I have also observed this firsthand. From my experience, I concluded that scope and quality were compatible goals and positively correlated. But I still didn’t really question the Iron Triangle. It wasn’t until I viewed this problem through the Lean perspective that the fallacy became apparent.

Agile Product Management Iron Triangle Less Time and Resources

Figure 2: The new reality


Lean looks to create fast, flexible, flow (see “Lean Thinking” by Womack and Jones):

  1. Flow value (e.g. products, features, enhancements) through the development system
  2. Do this in the least amount of time
  3. Only create a new feature or an enhancement when a validated customer needs emerges

A system that achieves the above would be considered “perfect.” Further, Lean teams spend time analyzing their processes to uncover waste: those activities, such as unnecessary documentation and long wait times that slow down the flow of value.

If we envision an ideal system, one that is 100% efficient, it is clear that we can increase scope and quality by using fewer resources and less time. Although physical constraints suggest we will never achieve perfection, it is still the target for which we must aim.

The Iron Triangle creates a mental block to progress.

It tells us we are doing our best: the relationships between outputs and inputs are fixed, and we can never expect to get any better. This is FALSE. It is time to jettison the Iron Triangle.

As product managers and product teams, we need to always look for ways to produce products more efficiently. Part of our job must be to spend time to reflect upon our current process, identify areas for improvement, and experiment with new ways of doing things. Some brave software developers did this in the early 90’s and out of it came the Agile movement and substantial gains in quality, flexibility, and throughput.

It is product management’s turn as a profession to question our beliefs and identify better ways to work.


Download All Of Our Free Resources Here

Download Now

3 Replies to “The Myth of the Iron Triangle”

  • Quality for me was always placed on a corner with scope so becomes a dimension because scope also contains characteristics of a solution not just features. I’m not sure I ever thought the triangle was immutable or equilateral in shape, but with any one delivery productivity of the process is unlikely to jump as you suggest. However I like the sentiment

  • Thanks for an interesting perspective on the proverbial “iron triangle” (love that moniker by the way!) I readily admit that I have had limited experience using the Agile development methodology, but I have seen that the development team can indeed accelerate their time-to-market and improve their end-product quality via effective bug-fixing while “in flight” by using Agile.

    However, I have also observed that the reduced bug-fixing time is directly related to the quality of the testing/validation process which in turn faces its own “iron triangle”.

    Time – how much time are the developers given to develop a test suite? There is a definite limit to what can be tested before it begins to slow down the overall development and release process.

    Resources – what resources in terms of test suite developers and equipment are assigned to the team? Every project and development is assigned an overall budget, and senior management demands that it be met.

    Scope – what is the “definition of done” in terms of what the test suite is able to test and validate? Some thoughtful time must be dedicated toward deciding how good the test suite really is in terms of its ability to catch bugs before the next sprint.

    I am not purposely playing devil’s advocate, and I honestly don’t have the answers to these questions, but I would be interested in getting the views and insights of some of the veteran developers and product managers who have been using the Agile development process for an extended period of time.

    • Brad,

      Thanks for the comment. Yes, I agree if we fix the process, the toolset, and the team then there is some optimal point where more testing will slow work down. The idea of the article is that some bright engineer decided to change the process in a non-intuitive way. The engineer said why don’t I take responsibility for quality and write a unit test before I even write the first piece of code. Thus test Driven Development was born. This shares many similarities to the work Deming did in total quality management. He said why inspect at the end of the process. That ensures scrap and rework. Let’s inspect at each stage applying statistical process control so we know everything coming off the manufacturing line will pass.

      The call to action is to look at your own way of working and ask can you work in a new way to break the bottlenecks or constraints that limit your ability to work more effectively.

What are your thoughts? We’d love to hear from you.

Your email address will not be published. Required fields are marked *