Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 77 posts at DZone. You can read more from them at their website. View Full User Profile

Is "Faster Better Cheaper" axiomatic in Agile?

08.17.2011
| 1477 views |
  • submit to reddit
“Faster Better Cheaper” - a cry heard often from management types!
Or at least engineers think thats the sort of thing managers say. Personally I don’t think I’ve ever actually heard a manager say it but I have heard engineers say managers want it “Faster Better Cheaper” with scorn in their voice.

The idea that you could have it (whatever it is) “Faster Better Cheaper” seems to have gained popularity when Daniel Goldin was the head of NASA. As many engineers, including myself, are quick to point out the original quote was “Faster Better Cheaper, choose two”. I say “original quote” but I have no idea who said it first, WikiQuote doesn’t help, and Google doesn’t shed much clear light. (Anyone out there know?)

Whatever, last week, I heard another engineer-type say that he believed management wanted “Agile” because it was “Faster Better Cheaper” and, not for the first time, it got me thinking. Is Agile Faster Better Cheaper?

My knee-jerk reaction is “No!” but the more I think about it the more I think it might actually be so.

Firstly, Faster than What? Better than What? and Cheaper than What?

Presumably “Faster than traditional Waterfall development”. Or at least, what-ever-it-is-you-are-doing-now, which is probably to some degree based on waterfall.

In the short run, when a team are first changing the way they work thy are quite likely to go slower than they would do otherwise simply because they are learning something new and not using a set of practiced reflexes.

Agile most definitely promises to deliver something sooner - if you want it, plenty of business folk seem unhappy with getting things too soon or too often. But Agile will NOT deliver the whole thing Faster, it can only promise to deliver a part sooner.

The logic of Agile recognises “You will change your mind when you get something”, meaning, if the business/customer sees part of the final thing they will add, remove and change the thing they originally asked for. In some cases, and I have seen this happen, they remove work. Lots of work.

Thus, the whole might come faster, but the whole is smaller than the thing you thought it was.

So, Faster - in the short run no, in the medium run you should get something sooner, and in the long run, Yes, it will look like Faster.

What about Better? - how are we to define better: better quality (fewer bugs), better suited to need, more fully filling the initial request.

Yes: Agile promises better quality (fewer bugs). Indeed if you don’t improve quality and remove bugs you are going to have problems doing Agile. If you do improve quality - fewer bugs - then the evidence suggests you will have shorter schedules, i.e. you will go faster.

Better suited to need: again, Yes. If those who made the requests are seeing something sooner, and having their views on functionality taken into consideration then one would expect the final product to be better suited to need.

More fully filling initial request: No, complying with “better suited to need” means we are not aiming to build the thing we first thought of but rather build the thing we need to satisfy the need.

So, if your criteria for success, for better, means complying with a requirements document that was frozen at some arbitrary point in time then No, Agile falls at this hurdle.

Cheaper: again there is a short run and a long run dimension here.

In the short run the development team need training, coaching and time to practice. Of course you could skip the training and coaching (plenty of teams do) but that means they will need more time to practice (make more mistakes, go down a few dead ends, etc.) Practice time costs.

In the short run I don’t think Agile is cheaper. Indeed, in the short run, if you are doing it properly you will see expenses rise as you have the likes of me come to train and coach your teams. (If you are not doing it properly you probably won’t see your costs rise but they will all the same as teams (slowly) learn by themselves.)

In the longer run, when you’ve finished the training, coaching and when the team are proficient then those extra costs will be gone and you should be cost neutral as least. But if you are not writing, finding and fixing so many bugs, and if parts of the requirements are being left undone - while satisfying your business customer - then costs should fall because you are expending less effort and doing less work.

Even if you are not doing less work costs should fall because on a software project costs are dominated by the number of people you have multiplied by the time you have them. If you are going faster then time is reduced and costs come down.

Therefore the project will be cheaper.

Summary: Better (fewer bugs) provides for Faster (delivery) which results in Cheaper (software).

Agile is “Faster Better Cheaper”, QED.

When you put it like that “Faster Better Cheaper” looks axiomatic over the long run.

The engineer in me hates this conclusion, I’m not prepared to accept it but if I follow the logic it is true. (The engineer in me would love someone to find a flaw in my logic so please go for it! Shoot me down!)

Note the three assumptions in this logic:
  • The reference point is the “Waterfall” model of development
  • Your definition of better considers a low-bug count important and emphasis fitness for purpose over conformance with initial requirements
  • Your are prepared to spend in the short run for quality (defect prevention) to save in the long run
How can we explain this? (Notice the change from ‘I’ to ‘We’, I’m pulling you into the conspiracy.)

Well, if this is true then its not so much that Agile is “Faster Better Cheaper” but that the model we are comparing it with - the traditional (“waterfall”) model - is so utterly broken.

Waterfall breaks Faster Better Cheaper everywhere:
  • Waterfall leads to large batch sizes and economies of scale thinking: in software development there are dis-economies of scale so large batch sizes makes everything slower
  • Waterfall project managers believe quality (bugs) can be traded off against time but actually the opposite is true. Reducing quality reduces “better” and slows a work down. The same project managers are trained to resist requirements change so almost guaranteeing business customers will be dissatisfied with what is delivered and consider it “worse.”
  • Slowing software development down makes it more expensive, remember: Cost = People x Time
Its not so much that Agile is a good model but that the competition is hopeless. It isn’t even a fair comparison. My belief is that Waterfall never really worked anyway, so comparing Agile to Waterfall is a false comparison - bang goes a big assumption.

In which case the, returning to the original question: “Is Agile Faster Better Cheaper?” the answer is really “Depends on what you are comparing it to.”
References
Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: