The (mostly) false idols of agile and waterfall project management

I’ve assiduously avoided getting into the agile versus waterfall thing for the best part of 20 years.

One of the reasons I’ve not got involved in this discussion is because – really – I don’t care! People deliver projects not methodologies. And that’s good news because that means ChatGPT isn’t coming for the project management community any time soon.

But sooner or later someone is going to say – “…well, y’know, the Vistogram is really just a tool for waterfall project management” so I’m getting my retaliation in first.

We seem to live in a world where any project with a Gantt chart is a waterfall project. There’s a lot wrong with that.

A waterfall project is a project that follows a set number of phases (specific phases too) and it’s strictly linear. In this more precise guise, I can honestly claim not to have seen one waterfall project in my entire career. No one does project’s like this. Ever. Note too that the methods put forward by Winston W. Royce in 1970 which were later badged ‘waterfall’, were broadly criticised (including by Royce himself) as being sub-optimal for software development.

Incidentally – since the Gantt chart preceded Royce et al by a good 50 years – it would kind of preclude anything using a Gantt chart necessarily being a waterfall project right?

Gantt charts exist. Linear project management with a defined scope exists. Documenting what you are going to do and then doing what you documented exists. But waterfall project management does not exist other than conceptually.

If linear approaches to project management are what we more commonly refer to as waterfall projects, then agile is iterative. More or less, we don’t define the scope up front – we iterate it as we go. Something worth mentioning too is that iterative methods existed long before the Agile Manifesto was written – it just didn’t take up nearly so many column inches (and nor did anyone make quite so much money out of it). Look up V-model development if you’re interested.

If the need for change is high and the cost of change is low (for instance, most software developments) then iterative approaches are a good pick. If the customer doesn’t know what they want, then trying to define a project scope up front is unlikely to be completely successful.

Agile town planning? Agile mega projects? Agile ship building? Agile drug development? No. Not really and not ever. That’s not decrying agility or saying it can’t have a role in all of these activities but no one is building a bridge iteratively. So if agile approaches can’t (usefully) be applied to all projects but rather a select few –  then for me, there isn’t really such a thing as agile project management per se. Yes – there’s a lot of agile canon out there. Much of it useful, most of it well thought out. Agile practitioners are frequently skilled technologists delivering change. In my limited experience, they are less often ‘full spectrum’ project managers delivering investments and transformations Neither one is better than the other. They are different.

Conversely, adopting a rigid ‘doctrinal’ linear approach is not a great idea either. Any belief that success is simply a matter of publishing a gargantuan project plan and change controlling the thing ruthlessly is flawed. You will be delivering the plan rather than the plan delivering the business’s objectives. We’ve lost sight of value and we’re simply tracking milestones and work done. We’ve all been there.

Thinking about the whole waterfall / agile thing in these more practical terms is helpful for all sorts of reasons. Opposing schools of thought provide little opportunity for there to be a practical continuum between waterfall and agile. The context and positioning of the topics has made them inimical to one another.

The perspective of linear versus iterative is unhelpful and suboptimal. It is much easier to imagine a continuum of shades of grey which we can move up and down depending on what we are doing. That’s not a methodology, that is judgement which is the very valuable contribution that project managers can make.

Finally, if anyone was wondering, Omnivisto® will be baking agile in to the Vistogram®. It’s on the back log.