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.
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.
Lean looks to create fast, flexible, flow (see “Lean Thinking” by Womack and Jones):
- Flow value (e.g. products, features, enhancements) through the development system
- Do this in the least amount of time
- 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.