Agile and Waterfall: A match made in heaven or not?

In this blog, I wanted to discuss Agile and Waterfall methodologies. Often they are discussed as separate to each other but I will try to show that these two ways of thinking are not in opposition to each other and can, in fact, coexist perfectly happily and deliver very successful projects.

“Agile Versus Waterfall” suggests that Agile and Waterfall are in opposition to each other, and that you can’t have one without the other.

First of all, Agile is not a method; you can’t run a project “using Agile”. Agile, like Waterfall, is a way of thinking. Agile thinking means being prepared to change what you are delivering, and responding to the clients’ responses to what you are producing, quickly. It requires all of your team to interact heavily with the customer and alter what they are delivering as a response to what the customer is telling them at the time. Waterfall thinking means giving your team a set of clear requirements and then leaving them to get on with it, which they should be able to do if the requirements are clear and they have an easy way of making enquiries to get further clarity, the teams do not necessarily need to interact with the client as much, as what they need to do is already documented. The Agile fundamentalists (and you should never trust a fundamentalist of any idea – the answer is always somewhere in between) would have you believe this this means that Agile and Waterfall are completely different approaches and that Agile is better, but the truth is far greyer than that.

First Agile is NOT BETTER than Waterfall. If you are delivering a project where change is complex and expensive, for example, imagine building a motorway where the customer can tell you to change direction on a whim, then an Agile approach could potentially be very harmful to the project. A very large and complex enterprise computer system with lots of interacting architectures could also react badly to multiple quick changes. It is possible, if the people on the ground know their business, that this approach could work in some complex environments, but it is a big gamble.

Second Agile is not opposite to Waterfall. Instead, they are two stops on a long continuum of project approaches. I have delivered many IT projects where we had morning stand-up meetings, and had regular meetings with the client where we presented mock-ups or basic functionality to show progress and get feedback, and these were in a “Waterfall” approach (PRINCE2, to be precise), where we had an overall semi-detailed functional spec from the start, but were still able to alter it as we went. This is Agile (interaction over documentation) within Waterfall, and it worked fine (usually!)

So, it’s not “Agile versus Waterfall” or “Agile OR Waterfall”. Think of these approaches as different flavours of ice cream; each are equally delicious, you may have your favourites, but they can also exist in the same bowl, perhaps with the hundreds-and-thousands that is spiral planning on top!