I like Agile but there are problems with it and those who ignore them will suffer for them. Here's a few

There's no fixed deliverable. From a developer's perspective that's Nirvana but now imagine you're the salesman who's got to sell a client on: "We can't tell you exactly what we're going to deliver for you and we can't tell you exactly when we're going to deliver it but whatever it is will make your life better. That'll be ten grand a month please." Agile software houses have to work as partners with their clients but the client doesn't really want a partner, they want functionality. Convincing them that the partnership will deliver the functionality can be easier said than done.

Agile has no critical path. It can't do because it has no defined end state. That means it's impossible to know when an agile development is slipping or how badly. If the whole project is geared toward "adding value" that's not a problem, but sometimes that's not enough. Imagine a politician being grilled on radio 4 on the progress of a wizzy new traffic control system. Can he really get away with saying: "We've delivered some improvement. It's ongoing. We think we're getting value for money." John Snow would eat him for breakfast. In some scenarios (particularly but not limited to government) a defined deliverable with defined milestones is a requirement.

Agile requires the client (or a representative of their interests) to invest considerable amounts of time in the project on an ongoing basis, both to test the delivered functionality and to feed in new requirements. Often they simply do not want to do this. I think most of us would agree that they should be spending this time regardless of the methodology being pursued but the reality of getting them to do so differs wildly from that. The consequences of that are that the team will deliver what they think the client wants instead of what they do want. Of course, with a waterfall you'd see the same effect... but at least you'd have a contract to cover your derrier.

Agile requires that the implementation be malleable. It's interesting to see folks saying that databases don't lend themselves to agile development and I suspect I know why. Databases are brittle. Get 'em wrong and your whole edifice crumbles. Any code in stored procedures will, of course, be procedural rather than OO and they tend not deconstruct to small elements easily. That means techniques like TDD are all but impossible to use against them. In fact, we came with a whole adjunct to TDD (dependancy injection) pretty much to avoid the unpleasant truth that we don't really know how to test the data that underlies our model very well. The data is the ultimte dependency... so we fudge it. Honestly, as a dev I pity the poor DBA, your life looks like hell to me. It's probably why you always seem so grumpy:-P. It's not just the DB that suffers from this either. If you've inherited some monolithic system written in the early 80's you'd be a fool to tell yourself that applying agile development to it's ongoing maintenance will be easy.

Finally, Agile assumes that functionality can be delivered in bite-sized pieces. Often it can't. Often the functionality is useful ownly in it's totality so what do we do? We run either run a long sprint or we run a series of short ones in which the deliverables are untestable... which is the same as a running a long one anyway. And what does a long sprint look like? A waterfall.

I really like agile but it isn't perfect. It's no more a silver bullet than OO was, or structural decomposition. There's a plethora of techniques that can help us deliver better software and the keyword there was "help". It won't do it for us and it won't always be suitable.