How can we persuade people that Agile Methods reduce costs?

I've just read this article by my friend Tim Diggins. I think it makes very clear why he uses Agile methods and what that actually means for him - as he says - what he does do and what he doesn't do. I don't think it's so good at convincing people who don't really know anything about Agile methods that they really lower costs - so here's my attempts, in note form.

Lower costs are what they're interested in so that's what needs to hit them first. It's like the story about James Thurber - he had a job as a crime reporter and he was asked to cover a murder on his first night. He reported how he'd heard about the murder, how the police had been alerted, who'd actually discovered the body. When he gave it to his sub-editor, the sub-editor said "No, no, no! This is all wrong! You have to start with the most important detail, the most important word even, first and then give the details in order of importance rather than chronologically"

So Thurber re-wrote his piece and started it off - "DEAD - that's how they found him!"

So how would this start?

"CHEAPER! That's what your software costs will be when you use iterative development." Even this is better. It's to the point but it's not obvious how to bring in the arguments you'd need to convince the reader.

Another tack is the Minto method:

• Bland statement nobody can argue with
• Sophistication/Complication
• Solution that deals elegantly with the Sophistication/Complication

So for Agile this might be:

Everybody wants to lower the costs of software development.
But this isn't easy because a lot of the costs are hidden.
They come late in the process because:

• That's when the clients and the developers realise they weren't thinking of the same thing
• That's when developers charge elevated prices for requested changes to recoup costs for wasted work
• That's when it becomes obvious that some new technology doesn't perform as well as the hype would lead you to expect
• These costs can actually be so high that the project is abandoned - the customers get nothing for their money - the ultimate high cost.

Iterative development [Here is where you would teach the concepts of iteration and working software] which produces working software throughout the lifetime of a project is aimed directly at reducing these late and hidden costs.

• Every time the client is presented with a new piece of working software, the understanding of the clients and the understanding of the developers about what the software is for and what it should do is tested. The chances of terrible misunderstanding (and big late costs) are reduced.
• Changes can be added throughout the project, because negotiation in an Agile project can be in terms of scope, as well as price, it may be that changes may have little effect on cost
• The emphasis on working software means that trouble with new technologies emerges early in the process. Something can be done early to work round the problem and find and alternative solution.
• Iteration by iteration the customers get closer and closer to actually having the thing that they want. At all stages they have *something* that provides the most important functionality. The chances of having to abandon the project are greatly reduced. Conversely, if a project just isn't a good idea, this will be obvious much earlier than with a conventional project, the costs of cancelling it will be reduced.