Skip to the essays
All essays

Agile Project Management—The Delusional Role

Bare with me, I’m trying to make a point. Read through, leave the flame wars for other posts. An Agile Project Manager is an oxymoron, a contradiction. You can’t be “agile” and “project manager” at the same time. Here’s some examples: Why? You correctly ask: BECAUSE the theories of the world for Project Management and …

An Agile Project Manager

Bare with me, I’m trying to make a point. Read through, leave the flame wars for other posts.

An Agile Project Manager is an oxymoron, a contradiction. You can’t be “agile” and “project manager” at the same time. Here’s some examples:

  • A chess master F1 driver (this metaphor does not work for boxing, see at the end)
  • A world class swimmer climber
  • A marathon sprinter
  • A tree that can escape a chase by a tiger
  • A fish that can climb trees

Why? You correctly ask: BECAUSE the theories of the world for Project Management and Agile are fundamentally contradictory!

Project Management is about UPFRONT planning, and CONTROLLED execution.

Agile is about feedback-driven, empirical management of complex work (i.e. you only have a vague idea of what you need to deliver in the end).

Project Management is about building constraints, and regimenting the work to fit those constraints.

Agile is about setting goals, and fostering enabling constraints (minimal, like the daily meeting, sprints, or flow metrics-driven work management), and letting the system (teams, technology, information, etc.) CONVERGE on the best possible outcome (which, remember, cannot be fully defined up front).

So, why do we keep seeing “Agile Project Management” roles out there?

Great question! My own take is because – in software – we never really applied Project Management to begin with. So, we got the impression that Gantt charts, and long excel follow-up lists were what Project Management was about. It isn’t!

Project Management is a very effective practice (system of practices, really) for CONTROLLING execution. The focus is on controlling (actuals vs. plan, estimation upfront, etc.), not RESULTS!

That’s why project management could never fit software – and never did – so it had to be adapted.

A simple example of this is the idea of “change control” (changes to the plan compared to the start of the project). If we were to implement the change control board practices in software, we’d spend all our time in meetings, not actually producing the software. Change control board (CCB), as a practice, only works if changes are minimal, and mostly concentrated in a specific aspect, or phase of the project. If they happen every day – like they do in software – the CCB grinds work to a halt!

It’s ironic that we still see Agile Project Management roles out there, but not surprising. Since we never – as an industry – really adopted project management, nor agile, we can just call whatever we do, by whatever name we want.

In other words, Agile Project Management means NOTHING, because the people using it don’t understand or apply either of these approaches. If they tried, they would very quickly find out that these approaches are CONTRADICTORY, it’s like trying to be completely dry outdoors in the middle of a monsoon. Not possible.

Keep the conversation going

The essays work best in company. Join the community to keep the questions coming.

The #NoEstimates book and its companion volumes

Chapter 1 · Free PDF

What if better planning started with a different question?

The first chapter of #NoEstimates argues that the “deliver on time” challenge is answered by a different question. Read it, and see whether it changes how you plan the next piece of work.

Free PDF of chapter 1. No purchase, no library access. How we handle your details