The five most expensive project agility mistakes

I really shouldn’t complain. After all, I have often made a good living from rectifying big project mistakes. But when Brian Wernham and I started our agile project management roadshows in the noughties we did so in part from deep rage. Rage against innumerable examples of organisations getting agility wrong then blaming agility – like a bad work-person blaming their tools.

If the trouble started anywhere, it was in Utah in 2001 with creation of the Agile Manifesto. Among many descriptions of agility, for me, this is the most coherent. Many criticise its simplicity of four values and 12 principles, but the latest PMI Project Management Body of Knowledge is also based on a set of principles. Unfortunately, principles are open to interpretation and misinterpretation – ask any theologian.

Deep rage was also one driver for me in writing Agile Beyond IT. So here is my take on the five most expensive project agility mistakes. Are they familiar?

Mistake #1: Thinking agility means iteration

Iteration is commonly held to characterise agility, being a recurring theme in software development agility. Yet iteration is not mentioned in the Agile Manifesto. “Continuous” and “frequent” delivery are, and iteration will give you this. But for anything above small developments, chunks of working software are not a “live” capability until they are brought together, maybe not for months.

And so, to projects. First, project management is about a great deal more than a life cycle. Why on earth would you limit agility to projects where an iterative life cycle is best? The flipside is that only projects with an iterative life cycle can be agile. That sounds crazy and is practical nonsense. I have led projects with agility with various life cycles and especially programmes with multiple life cycles. Agility applies to the whole of project management.

Second, this also means that the so-called agile v waterfall debate is nonsense as you are not comparing like with like. An entire approach vs a life cycle – really?

Mistake #2: Believing Scrum is project management

There is a saying: Scrum is agile but agile isn’t (just) Scrum. So true. The scope of Scrum is much narrower than the scope of project management – just look at the below example diagram of a project.

_{Figure 1: Copyright Pyne Consulting Limited 2022}

Yes, of course, Scrum has some aspects in common with project management, and yes, it is possible to adapt scrum. But why on earth would you, as you would end up with a creaking Heath Robinson version of project management? Frankly it is crazy, and yet it happens so much and mostly fails badly.

Mistake #3: The board does not ‘get’ agility

APM’s Fellow’s Forum on 15 June discussed how to raise the profile of project management and engage at board level. One clear message was that many at board level do not ‘get’ project management, let alone using agility. Why? Because most have a business-as-usual background rather than change, i.e. projects. It is a mindset thing. If you are used to keeping the show on the road then change is scary, leading change more so. As for agility, given it is around 50% mindset, then a great deal of learning and unlearning is needed.

Boards need to wise up quickly; as two 2021 PA Consulting reports evidenced, agile organisations are more profitable. And the evidence for the projectisation of work is becoming overwhelming.

Mistake #4: Senior management are insufficiently engaged

This is related to the board point and probably a consequence. Neither is it new, as it frequently appears in lists of the top 10 reasons for project failure. It has its own place again because of the behavioural nature of agility, and because projects succeed (or not) due to what happens both inside a project and what its organisational landscape is like. Put these together and engagement is critical to project agility. Absence of leadership engagement means you simply cannot have agility.

It is why agility does not suit some organisational cultures, as it might put them at risk. For example, think how disruptors like Amazon have transformed retail. Such disruptors have usually embraced agility.

Mistake #5: Thinking agility means leaving stuff out

The Agile Manifesto’s values have proved rich turf for the agilest snake oil salesfolk:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.

A clear mandate for leaving stuff out? Nonsense, they do not say don’t do process, nor documentation nor planning. Agility means doing ‘just enough’. No project professional does more management than is needed, which is why true project professionals exhibit agility without realising it. Agility can be a model for the right practice as it is adaptive to the project and its landscape.

I feel better now.

You may also be interested in:

• A project manager's guide to agile techniques
• Rigidity in project approaches needs to be addressed
• What is a life cycle?