But There Is a Flaw.
The traditional Iron Triangle concerns itself with things which are quantitative: cost, time to deliver, number of features, etc. However, most of the agile permutations have moved to qualitative measurements like value and quality. All of a sudden we are mixing something that can be measured objectively, like time, with something that is very very subjective, like value.
So… How Does This Break Things?
By comparing objective attributes with subjective attributes you no longer have the iron nature of the iron triangle. For instnace, it is possible to increase the amount of value created by doing the things are most valuable first. This increases the amount of value created without (necessarily) impacting the amount of time it takes to produce that value! You’ve “bent iron” so to speak. Another problem is that introducing test driven development and pairing increases software development cost in man hours and slows down time to complete. However, it can decrease man hours and time time to complete when changes are introduced later on in the development cycle.
It is also interesting to note that in the traditional iron triangle, adding cost normally means adding people. Brooks’s Law states that as you add people to an already late project, time to complete increases. This is an instance where even the traditional Iron Triangle breaks down.
So my final recommendation for those trying to apply a triangle to agile practices:
Use Triangles (Iron or Otherwise) as Mental Models.
Use them to observe, not control. Understand their limits. Understand where, when, and why they break down. Challenge the assumptions they make, and recognize the systems they were initially conceived in to explain. Remember: There are no best practices. Only practices with varying degrees of effectiveness depending on the environment in which they are applied.
Special thanks to Patrick Wilson-Welsh (@patrickwelsh) and Mike Cottmeyer (@mcottmeyer) for providing initial feedback and review of this article.
{ 2 comments… read them below or add one }
As one of the few self-declared agile product managers/CPOs around, I find the iron triangle discussion of special value with C-level execs who have astonishingly high hopes for agile. In response to their intuition that agile will immediately remove all barriers to instantaneous delivery of perfect software, it’s important IMHO to restate laws of software physics:
- if your wish/demand/requirements list is 12x your team’s current capacity, then radical improvements (e.g. doubling team’s velocity) will still leave you 6x short. Making hard, strategic, product-level decisions about what entire product lines not-to-build is still required. (Attacking feature-level value first is necessary but not sufficient.) Focus matters, and agile dev’t is not an excuse for undisciplined market thinking.
- execs mostly deal with quantitative items: revenue, delivery dates and stock prices. It’s our job to educate them about semi-qualitative items (e.g. quality) and the virtuous trade-offs implied in TDD, best practices, happy teams, good planning, relevant customer input, etc. Ultimately, they will demand a quantitative recommendation: “how many dollars/people/time should I invest in quality?” Reasonable managers must justify a specific level of investment.
- improvement isn’t instantaneous, so we need to keep counseling them on patience and reasonable timelines. I’ve seen too many organization give up when they are 80% along to success. But there should be an initial horizon, e.g. we expect to show improved velocity / quality / agility within a year.
Exactly. The triangle is a mental model that is widely accepted and understood by existing chief/director/vice presidents. Like all models, it has a purpose for existence and a context in which it can be applied effectively.
I am hoping this article will serve as a mediation point between those who view the triangle as a be all end all solution and those who think it has absolutely no bearing in an agile environment. Neither of whom are right
.