Skip to content
Our website will be unavailable from 17:00 GMT Wednesday 20 November until 9:00 GMT Monday 25 November while we carry out important upgrades.

If you plan to update your membership, book an event or access APM Learning, APM Community or use other resources, please do this outside of these dates.

The 15 November Chartered Project Professional submission date is unaffected.

Thank you for your patience.

The road to Agile project management - Agile for you and your organisation

Added to your CPD log

View or edit this activity in your CPD log.

Go to My CPD
Only APM members have access to CPD features Become a member Already added to CPD log

View or edit this activity in your CPD log.

Go to My CPD
Added to your Saved Content Go to my Saved Content

I have blogged much on two subjects in recent years. One subject is so-called agile project management, and the other organisational project management.

Good to see by the way that the latter is finally gaining a little traction. It’s a long overdue realisation that organisations need to create an environment in which projects - especially agile ones - can thrive, and not merely, survive.

Statement: Agile project management does not exist.

This is not a new message from me. My contention has been that anyone claiming a new project management method has to show clear blue water between it and other, existing methods. Books and papers I have read on the subject – so far – are adaptations, not creations. Nothing wrong with adaptation at all, except when it is claimed to be wholly new and different.

The DSDM Consortium are amongst those who have come closest. And they have not proclaimed new Agile PM, but adaptation (e.g. of Prince/2) to agile software development projects. Lots of gold stars to the DSDM Consortium.

Paul Bamforth in his webinar Kanban vs. Gantt, provided an excellent example of agile adaptation. Paul actually proposed an agile Gantt. Here, a high level Gantt would then be combined with Kanban boards for detailed task identification, ownership and delivery. Such a combination of “traditional” planning, and work lists is an adaptation I have recognised for more than 20 years.

And it was while chairing a conference which included Steve Messenger, Chair of the DSDM Consortium, that made me realise that, wait for it. Well that I have been wrong.

There is lots of agile project management.

Steve Messenger stated that agile is a state of mind. I had said something earlier about agile being at least as much behaviour as process and Steve nodded sagely (or nodded off).

APM’s Governance SIG is currently leading an initiative to develop a brief guide to agile governance, planned for release in 2015. I am hopeful that this avoids the trap of focus on process and recognises the cultural aspects of being project agile.

I still hold that I have not – yet – seen a compelling Agile project management method with clear blue water etc. But Steve Messenger’s point about the agile state of mind, coalesced a number of ideas I have been thinking about.

My conclusion is that we do not need an agile project (programme or portfolio) management method. This is because good project professionals are agile by their very nature and behaviours. They are output/customer focussed, flexible, self-organising, they embrace change.

So, the answer is not to develop agile project management methods, but to develop project professionals who are then, agile.

That is you taken care of, but how to make an agile project organisation?

This is where organisational project management comes in, and is much harder than the “you” bit as it requires organisational culture change. For an example of the challenges of trying to do an agile (development) project in a non-agile organisation, take a look at this animation.

The phrase “but I want to run an agile project” will become like a tune you cannot stop humming.

The key steps developing an agile project organisation for this are:

  1. Understand what an agile project organisation looks like
  2. Understand the existing organisation culture(s)
  3. Sell the value of being an agile project organisation
  4. Create a change programme to evolve and agile project organisation
  5. Sustain that change programme.

 


This blog supports my presentation to South Wales and West of England APM branch event on 9th September 2014. Slides are available here.

1 comments

Join the conversation!

Log in to post a comment, or create an account if you don't have one already.

  1. Patrick Weaver
    Patrick Weaver 24 October 2014, 07:23 AM

    There are two lines of thought mixed up in this blog - not good governance..1. An agile mindset is simply good management and better project management. Adapting to circumstances, engaging the client and using a phased approach to developing complex projects has been a basic tenet of good project management since at least the 1990s when Eddie Obgng  wrote the The Project Leader's Secret Handbook.  Having fixed preset scope cost and time budgets only works for projects in the painting by numbers quadrant in his matrix for more on this see: http://www.mosaicprojects.com.au/WhitePapers/WP1072_Project_Size.pdfThis is particularly challenging to organisations and PMOs that believe governance equates to a ridged set of processes! 2. Adapting project management processes to properly manage a project where the product is being developed using a agile methodology.  The light touch needed to make project controls useful in a project using Agile as a methodology was discussed in my 2010 paper that has gone through a number of updates since:  http://www.mosaicprojects.com.au/PDF_Papers/P109_Thoughts_on_Agile.pdf The challenge with governing either of Agile the agile options above is that the governance systems and the project management systems need to be far more outcome focused and have greater degrees of trust in the people involved in the work than more traditional processes.The key requirements are:-         Making sure the people are appropriately skilled -         Making sure the project objectives are very clear-         Understanding the difference between developing a defined capability for the optimum cost and developing the best product possible within a set cost and time box. Agile works well in both situations but you can only have one as an objective. For more on of my thoughts on Agile see: http://mosaicprojects.wordpress.com/category/general-project-management/agile-ideas/