Scrum, agile and "real' project management methodologies

I have been following a blog "Better projects" for a while. A recent post arguing that "scrum" (an agile software development methodology) can represent a complete answer to project management for certain projects, reminded me that I had been intending to post a couple of thoughts on this matter myself:

In my humble opinion, agile project management (as a philosophy, rather than the specific flavour of agile suggested by Jim Highsmith - see also here for more on that), informs all areas of project management and the application of the principles found in and around the agile manifesto, can certainly provide answers and guidance to most/all parts of a project.

This does not, however, necessarily mean that scrum can entirely replace "real" project management methodologies.

In the context of full disclosure, I feel I should out myself at this point as a fan of agile approaches in general and - on the whole - of scrum as a specific flavour of agile (though, as with any methodology it has advantages, disadvantages and should be applied carefully, taking into consideration the context of the actual project...).

A few years ago, I did a bit of thinking about how the various agile frameworks map to the various project management disciplines and how they can effect the degree of risk on a project as part of a Masters degree that I did in my spare time. Back then I came (amongst other things) to the following conclusions:

• There is little that is contradictory between more traditional project management "meta"-frameworks like the PMBOK from PMI and agile methods though they do not bear direct comparison in all areas and in some areas they extend into software development (ie. domain specific disciplines) not covered explicitly by project management frameworks.
• Conversely, PM frameworks do address explicitly areas that are only implied or hinted to in agile.
• As such scrum can usefully be augmented by other practices (particular in the area of HR, but also in procurement, risk management, cost management etc.).
• Usage of scrum (and other agile methods) can lead to a reduction in risks on projects
• ...But this depends entirely upon the way it is applied.

I guess there should be no real surprises in these statements, but I was surprised by the fervour with which this stuff is discussed (both in real-world practice and academia) - just google "scrum-sucks" for a lively critique of the practices (and in particular the overzealous application of a idealised methodology on the real world).

It should be noted, that this thinking was done in an academic context and consequently involved a good deal of defining and differentiating terms (eg. agile "philosophy", "method", "methodology", "approach", "framework"), but I still absolutely stand by the findings (and they have been stated in the meantime several times over by many people much smarter than I (see also here for more details from someone who really understands this stuff in detail!): any framework is just that, a framwork - it does not replace thinking and applying one's knowledge to a given environment and project to adapt and use a framework.

I have nevertheless attached a few of the overview diagrams from the introductory/definitions section of the paper below for those that might be interested:

1. "Framework" for the analysis that combined "pure" project management and software development frameworks (since I argued that many of the agile project management approaches stretch across areas of both such frameworks):


2. An overview of how scrum and xp map to this framework



3. The resulting mapping of these methodologies to the idealised framework (where a "full-score" would be attained if all areas were fully addressed - unrealistic for any framework).


If you are interested in more detail and the other findings (based upon survey and case-study, and more explicitly describing the ways in which different types of risk are addressed using agile methods), please contact me directly, since the material cannot be shared in its entirety without permission from the university, myself and the participating companies.