Don't get me wrong, there's a lot to like about the Agile Manifesto and even more to like about the 12 principles which underpin it. (I must remember to say the words "...maximizing the amount of work not done is essential" in my next job interview). But neither of these things are (in themselves) project management.
I can understand the appeal of Agile to programme stakeholders. If you've adopted Prince 2, all your requests for change should technically be added to the issues log. This can sometimes lead to a distinct cooling of the relationship with the sponsor when (inevitably) it is their requests for change. And it's not just Prince 2, if you've adopted the PMI/PMP standard, then one of the sponsor's key roles is to defend the project from change.
Against this, Agile adopts the persuasive position of "Welcoming changing requirements, even late in development." And, show me the techie who wouldn't heartily endorse the value of "working software over comprehensive documentation".
But since there isn't actually any such thing as "Agile Project Management" per se but rather a collection of iterative approaches (namely; Scrum, Extreme programming, Agile Modeling, Unified Process, Agile Data, Kanban etc) what exactly were you after? Because if you don't know the answer to that question - I certainly don't. (It might be that by the time I've finished this post - there will be such a thing as Agile Project Management - its a fluid landscape...)
Is Agile something of an emerging 'norm' in software development (and selected other) projects? Undoubtedly. But I'm not even sure if that's the point. If you're a programme sponsor or budget holder attracted by Agile techniques and want to know what you are going to get and when you are going to get it, you might want to validate that Agile can answer these questions to your satisfaction.
But you've heard all sorts of good things about an iterative approach and you want one? Fine - adopt v-model development or incorporate specific iterative elements into your project methodology either by tailoring Prince 2 or adopt PMI / PMP which already has a healthy iterative element in its planning cycle.
Personally, when I hear the word Agile used on projects I'm usually on the immediate look out for either of the following potential issues;
- Is the project simply too big to satisfactorily drive out one set of objectives and requirements (in which case it should be split into multiple projects)
- Is your schedule so tight that to spend the time required on planning "is going to place the schedule into an unacceptable negative schedule variance".* (in which case you should hire
in somelots of very smart planners, recognise you're running at high risk and adopt rolling wave project planning
*Credit to Wikipedia for turning 1 syllable (late) into more!
It isn't my view that Agile 'anything' is necessarily the antidote to these two potential issues.
The author is a business focused, benefits driven project manager with no formal qualification in Agile and no experience whatsoever in developing software. Other views undoubtedly exist.