Scott W. Ambler compares software development to the iron triangle as follows:
He states the problem rather elegantly:
| Recognize that the iron triangle must be respected. The iron triangle refers to the concept that of the three critical factors – scope, cost, and time – at least one must vary otherwise the quality of the work suffers. Nobody wants a poor quality system, otherwise why build it? Therefore the implication is that at least one of the three vertexes must be allowed to vary. The problem is that when you try to define the exact level of quality, the exact cost, the exact schedule, and the exact scope to be delivered you virtually guarantee failure because there is no room for a project team to maneuver. |
For a Software Project / Product to be successful, we as development teams and above all, as responsible individuals, need to learn how to elasticize the triangle. Scott suggests over four ways to introduce elasticity in his article. He suggests that you can actually alter any side of the triangle, depending on your project / situation.
Andy Hunt and Venkat Subramaniam in their book – Practices of an Agile Developer suggest time-boxing as an answer:
| “Setting a near-term, hard deadline for an activity that cannot be extended. You get to choose which other aspect will suffer, but the deadline is fixed. You probably don’t know the exact number of time-boxes that are required to complete the overall task, but each individual box is short, is finite, and accomplishes a clear goal-setting a near-term, hard deadline for an activity that cannot be extended. You get to choose which other aspect will suffer, but the deadline is fixed. You probably don’t know the exact number of time-boxes that are required to complete the overall task, but each individual box is short, is finite, and accomplishes a clear goal.” |
The book offers a very real example (which I can relate to from past projects that I've worked on):
| For example, iterations typically run a couple of weeks long. When the time is up, the iteration is done. That part is fixed - but the set of features that makes it into that particular iteration is flexible. In other words, you never slip the date, but you may slip a feature. |
I’ve seen developers around the world (I refer to them as Fred :)) give-in to the temptation and try to make the triangle elastic by lowering quality. We (a mentor and I) also even went ahead and termed this - the Junior Developer Syndrome.
Having said that, Time-boxing really works wonders in introducing elasticity into the triangle and at the same time maintain sanity! Especially if you are shipping projects / products with a strong leadership and a mature team that will not compromise on quality.
As developers, we all suffer through the I-can-do-it syndrome. It’s easy to get into trap by having a conversation with a marketing person / client, which goes somewhat like –
“Can we build this?” – Developer: Sure.
“Can we build this in 3 months?” - Developer: Ummm….
“Thanks! Our current team is enough to build it, right?” – Developer: I think so... I...
“Great! Thank you so much! Let’s start building it then!”
The next time you estimate or say “yes” continuously in a conversation like the one above ask yourself – have you respected the iron triangle? Have you left enough room for elasticity? If you haven’t, chances are that the fourth dimension - quality - will suffer. Time-boxing, prioritizing features and dropping the ones that don’t really add value is the safest, smartest way to introduce elasticity into the triangle. When in doubt prioritize up-front!
Comments are closed.