These 'episodes' were originally four separate posts on LinkedIn. They proved to be extremely popular and have been brought together here to appreciate the complete argument.

Episode 1

The Agile movement has greatly enriched the project management landscape. Unfortunately the ‘cult of Agile’ is doing more harm than good with its narrow evangelical views. Project management has always included elements of agility and I have pointed out on numerous occasions that agility is a continuum with ‘Agile’ simply being at the extreme end of that continuum.

Over the next few weeks I plan to post some examples of natural agility within projects. I'll keep them brief and succinct and I'm sure more detail will come out in the comments.

Let's start with 'There’s no such thing as a waterfall project – episode 1'

Many people cite construction projects as the epitome of waterfall. So let’s have a look at a typical construction project.

It starts with a customer deciding they want a building. They engage a multi-disciplinary professional team comprising Architects, Structural Engineers, Services Engineers, Surveyors and others.

This team works to understand the client’s requirements and ‘digitally’ builds what the client wants. This will involve many, many iterations of the design until the client (and local Government) is happy with the end results and the various disciplines work out how to integrate their varied technical designs.

The team operates with great agility and is able to do so because when you are building something digitally the cost of change is very low.

So the point of episode 1 in this series is ‘Every construction project starts with great agility and always has done’.

Episode 2

In episode 1, I explained that all construction projects are designed in a very agile way. The assumption among those who want to perpetuate the rigid ‘Waterfall’ myth is that once construction starts in the ground everyone ‘follows the plan’ until the end product is delivered in a big bang. In contrast, a defining characteristic of ‘Agile’ projects is incremental delivery.

It’s true that some construction projects cannot be delivered until completely finished – take a bridge for example, half a bridge is no use to anyone.

But there are many other instances where construction projects are delivered incrementally. The classic example being housing projects. A good size housing project may include 100 properties. The developer needs cash flow and the project will be designed in such a way that houses can be delivered incrementally and sold before the entire estate is complete. It may well be that the full complement of 100 properties are grouped into five ‘releases’.

Within each release potential buyers will look at the basic product and then specify their preferred finishings, meaning that the construction team have to respond to the requirements of 100 customers in 100 incremental deliveries across five releases.

The point of this episode is that ‘Incremental delivery is not a unique, defining characteristic of so called ‘Agile Projects’.

Episode 3

One of the misconceptions that people promote about ‘waterfall’ (or the even worse phrase ‘traditional waterfall’) is that it’s all about ‘following a plan’. I recently read a transcript of a presentation about the building of the Empire State Building in New York, written by someone who appeared to be using it as an argument against planning.

One phrase caught my eye:

“The minute it rains or somebody doesn’t show up or something takes a little bit of extra time or something like that, [the plan] falls apart.”

To me, this demonstrates a fundamental lack of understanding of the planning process. It is typical of those who argue that in the mythical world of ‘Waterfall’ everyone works rigidly to ‘The Plan’ and chaos ensues if any small changes need to be made – which, allegedly, means that it’s better not to plan in the first place.

A plan (or schedule to be more accurate) is simply a best estimate of the future performance of the project at a point in time. As Mike Tyson so eloquently observed “Everyone has a plan ’till they get punched in the mouth.” All that means is that when your plan gets punched you rework the plan.

I have never known any competent planner who doesn’t fully appreciate that the plan will change after the first progress update (and the second, and the third and so on). We continually learn as the plan is updated and adjust our future plans accordingly (sounds quite agile in an ironic sort of way).

So to those people who think that all those working to a plan are some kind of robots that wander around lost and aimless when their plan is affected by a rain delay or late material delivery – think again (please!!!!).

Episode 4

My previous three posts in the ‘There’s no such thing as Waterfall’ series have generated a lot of great, well-informed debate. I started off with the intention of debunking what I perceived as the concept of Waterfall as an antonym for Agile.

It was perhaps naïve of me to not anticipate that there are many, many different views of what the term ‘Waterfall’ actually means. That shouldn’t have been a surprise since there is a similar lack of common understanding of what ‘Agile’ actually is, so if Waterfall is the antonym of something that isn’t well defined, why would I expect the term Waterfall itself to be well defined? Rookie mistake!

All of this has reinforced my view that in the world of project and programme management, we should stop using the terms Agile and Waterfall (and, as a consequence, Hybrid) and just talk about agility. All projects demonstrate some degree of agility at some point in their life cycle and agility can take many forms.

Let’s stop this reductionist approach of trying to classify everything as either Agile, Waterfall or Hybrid – it simply doesn’t work and will only lead to more project failure because those new to the profession will think you have to be one or the other, rather than taking an approach to agility that matches the context of the project.