@ Jeff: Sorry you had a bad experience with agile. Not all agile teams are truly agile. Our team delivers quality software without a hitch using agile...ask any of our clients.

@Darren: OK, you're right on one count, this was oversimplified...to make a few points in an un-narrated video. But it's not far from the truth. In my estimation, you're subscribing to the water-fallacy that if we spend enough time really defining requirements and design up front, everything works. Consider this: The Standish Group's Chaos report finds that of all software development projects using the waterfall methods, only 35% were successful (that means the other 65% either went over schedule, over budget, or didn’t deliver on the scope). A few more waterfall stats for you to chew on:

(1) Nearly 2/3 of projects significantly overrun their cost estimates (Lederer and Prasad, 2002)

(2) 64% of features included in products are rarely or ever used (Johnson 2002)

(3) The average project exceeds its schedule by 100% (Standish 2001)

This has nothing to do with how good or bad the dev team is. I've been on great dev teams stuck with a waterfall methodology and we continually failed miserably. The current dev team I manage is one of the best I've ever worked with. Before switching to agile, they consistently had difficulty either staying on schedule, on budget or delivering the full scope of their projects. Since we adopted agile, we haven't missed on any one of those yet...and it's been quite a while now.

What you may not understand is that in agile, we write contracts that support this project management style. We don't fix scope so we don't have to argue over it. When a client makes a change, it's already part of the contract that they CAN make chanes anytime they need to. And cost is not an issue either. We write contracts in one of two ways with regard to cost: (1) Open cost model, we're done when the client says we're done. The client has complete control over cost; (2) Fixed cost, where the client constantly prioritizes their "requirements" to ensure they receive the most value first. When the money's gone, the project is done, but the client receives high value. What the client doesn't doesn't receive is waste...you know, that infamous 64% of features that rarely or never get used. Those usually get prioritized out of the project...by the client. And finally, there is no re-scoping since scope is flexible from day one.

Too many people subscribe to the waterfallacies and agile-phobias that you've mentioned. Hopefully, we're doing our part to dispell those.

P.S.: If you want those references cited above, email me and I can provide them to you.