An AGILE Discussion
Posted by Dan Strayer on 30 September, 2011 - 10:03
With an eye toward developing Project Management Tipoffs content for the October issue, Agile is our subject heading today. To drive the conversations about this method and its emerging presence in PPM, we host here a discussion on the issues pertaining to Agile. We'd love to get both the APM view and its many individual's view about that emergence, and whether or not Agile (particularly DSDM Atern and its adoption by APMG in a new OGC-sponsored certification for agile project management) may be a challenger to the PRINCE2-dominated PM method market.
Some questions to stoke the debate, if I may...
-Could Agile, in fact, be PRINCE3?
-Government ICT projects will now have an Agile governance. Yet is the perceived lack of structure/planning of the method a positive or negative for IT projects?
-UK governement IT developed and evolved PRINCE2. With a couple of generations honed in on this method, does it easily & quickly lend to quick adaptation of Agile governance?
-Agile has something of a perception that "it's only for operations management". Does DSDM Atern (or other iterations) change that in practise? What about in the PR battle against sceptics?
Sceptics and advocates both: the floor is yours!
Posted in
APM welcomes the use and development of methods in project management and the role they play in contributing to project success. As with all methods, it is the way they are applied to the projects that is important. The ‘slavish following’ of a method, without consideration of external factors will generally lead to unsuccessful outcomes, as methods are only part of the story.
Effective delivery also includes the maturity of the organisation (demonstrated through the application of maturity models), the appropriate knowledge (of which APM’s view can be found in the APM Body of Knowledge) and demonstration of appropriate competences (for example, those represented within the APM Competence Framework). There are certain functions that must be carried out in projects, for example managing scope, risk, cost etc, however there is a broad range of tools, techniques and methodologies that are available to practitioners to achieve this. APM intentionally do not prescribe how functions are carried out as this decision is dependent on the project and the context in which it is being managed.
Dan Strayer asks a number of quite provocative questions, which I find interesting as it prompts thought; and drives thinking further.
Will Agile become PRINCE3? Personally I don’t think so. Although quite good as a method, PRINCE2 in my opinion is quite mis-understood. Many believe (or perhaps believed) that if you followed PRINCE2, you would be successful, and of course this has turned out to be false; for a variety of reasons. Slavishly following any method without considering external factors will inevitably get you into trouble, and I believe the same is true of AGILE.
AGILE as a concept is not new – the name is, and lots of the hype and the training associated with it, but change within a project is not new. The problem has been that slavishly following a method (like PRINCE2) has had a negative impact on the agility of project performance because of the ‘change management’ processes within the method. All documented methods that I know of cater for changes within the project; however, this is often perceived as preventing the quick reactions to changes within a project because of the burden of the change management processes. BAU managers, including naïve sponsors, see this as road blocks to implementing change.
AGILE is a viable project method, but it does have some disadvantages. In older or more traditional project management methods, the concept of re-work helped to control costs; it helped with understanding the impact of changes, often not getting it right first time and of course with lessons learned. If a project is re-planed and re-base lined at regular intervals two things happen. The project never appears to be late, and re-work costs are eliminated. Depending on your perspective, these could be quite attractive.
As a person who has been practicing and teaching project management at all levels for well over thirty five years, I like to have the option of deciding what methodology or combination of methods I want to use for any given project. This does mean that as a project management practitioner I need to understand the advantages and disadvantages of each method (like PRINCE2 / DSDM / AGILE / traditional / engineering / construction / etc.) and how they can be combined for the most effective delivery of my project.
Being tied to one specific project management method regardless of what it is deprives me of the flexibility of using the most appropriate techniques and processes to achieve success.
John Zachar, FAPM
I agree with John, Agile is a sometimes useful content development methodology (it can be used for a range of project in addition to software development). PRINCE2 is a project delivery methodology.
One of the key strategic decisions that needs to be taken early in a project is the methodology to be used to create the deliverable. See, Agile is NOT a Project Management Methodology: http://mosaicprojects.wordpress.com/2009/03/05/agile-is-not-pm/
A good post on selecting the right projects to use Agile in is at: http://mindavation.com.au/wp-content/articles/2010_05.html?keepThis=true&TB_iframe=true&height=550&width=750
If the product development method chosen is Agile, the way the project is managed within the overall framework of PRINCE2 or any other methodology changes but the changes are subtle. See: http://mosaicprojects.wordpress.com/2009/03/07/managing-agile-projects/
And then just to really confuse issues, Agile concepts can be usefully applied to project management to kill off a lot of unnecessary bureaucracy! See: http://mosaicprojects.wordpress.com/category/general-project-management/agile-ideas/
Be wary of the agile-anarchists who advocate the total abandonment of any process (the catch cry is to “trust them they are all above average performers” - their grasp of statistics is interesting....). What’s needed is the effective use of Agile in the appropriate situations with appropriate governance systems.
In BT we have looked at the Agile model for delivery since 2006 and I presented on the Agile approach to project management to the East Anglian group of the APM at the end of 2009.
Much of the "perceptions" are indeed more like "Myths" and if Agile delivery was as described by the myths then it would be foolish to adopt. However it is built on sensible values that reflect the need to deliver for our customers in changing world.
Historically Agile has grown out of small scale IT projects and that is where most of the work has been done. However, the benefits are not constained to that domain but it does require some careful thinking to adopt in large scale non-IT related work, Some types of project will not benefit from an Agile approach and some will. If there is a lot of change and instability, then an agile approach is more likely to succeed as there is a very short horizon of prediction.
To help in any battle with sceptics I would look at the splendid record of delivery of large scale projects in the chaos reports from the Standish Group. For example see: http://theagileexecutive.com/2010/01/11/standish-group-chaos-reports-revisited/