every customer thinks he wants a fixed price contract because that gives him the illusion of security. He won’t spend more money than he’s agreed to in the first place, right?

Well, I haven’t seen that yet. Waterfall driven projects get delayed, go live buggy and the IT company will do what it can to make up for the initial loss of money in future enhancements, add ons, changes etc. In the end, the project is more expensive than the contract indicated. This is traditional software development. If your company is accepting change requests without charging the customer, you have a problem. (Your company is one of millions, but that doesn’t make it better)

Take the time and explain the benefits of agility to a customer:
- He can change any requirement at any time, provided that it hasn’t been started yet (because you embrace change). During the re-estimation he’ll be present and can decide whether the cost of the change is worth it.
- He can have a release early, even if not all requirements are implemented yet. (because you deliver potentially shippable software at the end of every sprint)
- He’ll get the chance to have frequent updates and check the progress as often as he wants, even give his comments and feedback. (Because you show him the result of every sprint in the review meeting)
- He can add new requirements at any time. Either the project’s complexity increases (time and budget) or he removes requirements of equal size to keep complexity constant. (again, embrace change)

Coming to your comment – ask yourself: If in your waterfall project you need more time or budget than your initial requirement indicated, what has happened? In my experience nearly in all cases the requirements were not clear enough (causing your estimation to be wrong) or the requirements changed throughout the project (adding more work).

This is no one’s fault, it just happens. IT is hard and complex. Agile approaches acknowledge that. Your estimation will probably not be better in agile (but also not worse).

Traditional software development (waterfall) encloses the customer in a very comfortable bubble (SRS, fixed price, …) in the beginning. But that bubble is bound to burst, leaving the customer to a rude awakening in the end stages of the project when any change is very expensive.
The benefit of agile development for your customer lies in transparency. At any time he will know where his money goes and if he needs to increase the budget. He can decide what to do.

In my opinion that freedom of choice and this transparency is worth it.

Thanks and best regards,
Manuel

I’m very familiar with the same issue, but in the end this is not a problem that arises with agile. You’ll have to do an estimation based on the requirements even in agile (release planning level). So yes, the customer will know roughly how much it will cost. You will want to do that estimation for yourself anyways because otherwise you won’t know if the project is financially interesting for yourself, how long the team will be busy with that project etc.

The confusion comes up because of the possibility for the client to change the scope during the project I guess? Well, do you have non-agile projects where that does not happen? I guess not. So change is there anyways. In a non-agile project change is a risk, called a CR and causes a lot of heated discussion. Agile embraces change, that’s all.

Hope that clarifies it a bit.
Best regards,
Dominique