The big difference

If you'd ask me what is the top-of-the-tops of advantages of Agile development, I would go for ... Hmmm. It's always difficult to mark one specific item, but I'd say Risk Reduction is the main thing.

The funny thing is that the Requirements-Specs-Analysis-Design-Implementation-Test-Introduction-Maintain  (aka 'Waterfall model') people try to claim this, but they're dead wrong; it's exactly the opposite from what they claim. Waterfall procedures are almost a guarantee for overruns and blatant failure. And always producing mediocre results (if any).

Value levels

Agile methods are much better suited for reducing risk, especially for avoiding all-out failures. By concentrating on 'value level's you can always work towards useful products - in terms of user, or developer value. Value levels translate into milestones. Very commonly, we get the following milestones:

1. Initial demonstration model (executable!)
2. First actually usable 'system'
3. First acceptable but no-so-luxury product
4. Satisfactory, worthy product
5. Great software

In agile you need a development toolbox that allows taking software onto higher levels all the time. Where Waterfall produced series of build-and-dump prototypes, Agile just goes on with the same executable model. This requires re-shuffling of activities.

Trust is key here. The users have to trust that the developers will always seek to optimize user value. Developers must make sure they always live up to that code of ethics. This is a question of integrity. For Agile team managers, integrity in of the team is one of the main issues. Team members with 'hidden agendas' or other sneaky ideas about how to work need to be expelled at all cost. I can't stress that point enough.

Risk reduction

Back to risk reduction. By striving to get these milestones ready as early as possible (usually whilst releasing early and often) you always head for systems that at least do something useful. There always is maximum user value at each point in time. After (1) you have a great tool to discuss what's needed with users, how things should 'look&feel', and so forth. For the software developers, it is even more important. Everything present should be working with a final system in mind. This gives the blueprint of the design/architecture concepts used for the product. After (2), users can do actual work with the system (in a Spartan sort-of-way). Next is a product that you could introduce without problems, albeit that there is a feeling of unease among the parties. Getting stuck at this level is often a question of budget/funding. After that, the only way is up.

Conclusion

Working in terms of value levels gives great risk reduction. People say that half of the software built anywhere never makes it to the work floor. Agile is the way to minimize that risk. No guarantees will be given up front other than 'we will make it as good as possible'. Live by that rule; always have the maximum user value in mind - that's what Agile is all about.