The waterfall approach
My last two software development groups switched to Agile while I was part of them. In both cases, it was a relatively amazing experience for me. Instead of towards a long term goal and finding out just how far off the mark we had been from the start when we finished, we were able to change directions so quicker in the middle of development.
If I was to plot a big project's path before we started with Agile, it would look something like this:
The agile approach
Compare that to our path under agile:
Back to the stone age with you!
My current project is using more of a waterfall approach to designing an API. Instead of biting off tiny chunks of the API for development and building the client to go along with it, we're building the API out fully first, then building the clients to consume the API.
So far this has already led to lots of wasted effort. If I think I understand the business case for something and build an API for it, the API will work awesome until I try to use it for a real-world test. Then I find out that the definition of a concept I was operating under is wrong. So then to get the client to successfully consume the API I have to write the client and change the API at the same time.
We had a contractor work for three months on a large segment of the API that we ended up completely not needing. While working in a more Agile way wouldn't have kept him from writing all of the few thousand lines of code that has been since deleted, it would have shown us much earlier that he was going down the wrong path and at least some of his work may have been saved.
Agile wants a usable piece at the end of each iteration. That requires building at least an example client along with the API.