I rant and rave at people who advocate agile as being "agile is the way to do everything, you're either agile or you're doing it wrong, agile will solve all your problems", because generally they're trying to solve the wrong problem.
The problem is that "agile" is such a buzzword for management that, like most buzzwords, they don't see past it and believe it's a magic bullet. "Never mind the problems caused by the business, clearly the problem is the developers aren't 'agile'. So we don't have to address our actual problems, just tell IT to be 'agile' and it'll all be fantastic."
A lot of this problem is caused, or at least made worse, by the slew of terrible books about "how to implement agile" that spend most of their time parroting this ridiculous utopian notion that you don't need to do any actual thinking, or make any changes to the any other part of the business, just adopt "agile" software development processes and everything will come right (agile in this case being nothing to do with the agile manifesto, but whatever snake oil training said "agile practitioner" wants to sell you).
And yes, there are organisations who actually make agile work, but they are few and far between as far as I can tell, and I've tended to find that they would probably work pretty well with almost any project management process, for the simple reason that they encourage clear requirement finding and definition in the first place. Which is, let's face it, the thing that actually makes the most difference anyway, regardless of whether you adopt agile, PRINCE2, waterfall, SSADM or any other requirement management process.
Biting the hand that feeds IT
