Waterfall vs. AGILE: 2 pillars of project management

If you only start to work in Tech or you have some experience but would like to step in to deep waters of project management, you probably heard about 2 fundamental approaches to implementing IT solutions which are Waterfall and AGILE.

Many of us who work in IT are sure that it is possible to use either one or another, but you can’t combine them. There’s also an opinion prevails that AGILE should become a de-facto standard for all projects done under the Sun. Let me give you my perspective which I got after 19 years in project management. I believe that the reality is a bit more complicated and flexible than it is commonly believed.

First let’s start with some basics. What is Waterfall and AGILE and what are their main differences?

Here’s how Forbes explains what Waterfall is:

Waterfall methodology is a widely used project management method with a linear approach. In Waterfall, each stage of the workflow needs to be completed before moving on to the next step. While there are various types of project management methodologies, Waterfall is well suited for projects where the objectives are clearly outlined from the beginning.

Indeed, there are 5 phases: Requirements, Design, Build, Validation and Maintenance. In classics you need to follow each of them one after another. Here’s what happens in those phases:

Now let’s talk about AGILE. This is a newer approach: in comparison with Waterfall established in 1970, AGILE Manifesto (main document stating AGILE principles) was published in 2001. It’s 68 word document, so I’ll list it here in full version. This what it contains:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

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

That is, while there is value in the items on
the right, we value the items on the left more.

In short, this new way of project and product management is oriented on iterative approach to delivery of solutions: instead of getting one big list of requirements, then designing, developing and testing the whole solution based on it, AGILE principles recommend to do all of those stages many times for tiny pieces of functionality. Every such cycle should end with demo of solution feature developed to stakeholders, getting their feedback and incorporating it into next iteration and releasing developed piece for end users.

AGILE became an answer to problems emerging from Waterfall approach. For example, if you first gather all the requirements, designed and developed everything and in testing phase one of customers remembers that he/she forgot to include couple of super important elements of functionality, then overheads to correct the situation may be too high: you need to go back to your 200 pages user requirements document, include new elements in there, reconfirm it with everybody, change design to accommodate new features, change code, change testing process…

Another situation often happens with pure Waterfall is when delivered solution does not look like what stakeholders wanted because without regular demos of pieces developed they can’t really imagine how exactly IT tool will look like. Requirements they gave to the team in the beginning were theoretical vision, they might mean something else in practice, team might misunderstood their wording and vision etc. You all probably saw those memes when it was asked to build swing, but what really was developed looked more like a helicopter)))

There’s a standard within the Industry that Waterfall is being used for situations where you have all the requirements clear from the very beginning and you have limitations in timeline, so you can get more resources, but you can’t overstep certain deadline. AGILE, on the other hand, is used when requirements are not so clear and you need to move step by step with iterative approach to find the right balance between speed of development and compliance with requirements, you’ll give your stakeholders a chance to experiment and change future product configuration on the go.

In practice, however, Waterfall holds all the risks described above even you THINK that you know all requirements from the beginning — it’s too dangerous to go in a free sail without regular revision of what’s done with customers.

Now after this retrospective it looks like Waterfall goes to the past and AGILE is our new everything. It’s not quite right.

First of all, pure AGILE may not work in some specific project situation. Read my article about it.

Also, it’s quite often when team prefer to blend the approaches. For example, who said that Waterfall could not include iterations or phases? Spend couple of sprints for requirements gathering and approval, then 2–3 sprints for design, 4 sprints for development, 2–3 sprints for validation and voila — you have a product which you did following Waterfall 5 stages golden rule, but those were organized in AGILE sprints with regular customers’ feedback incorporation. It’s not a given, that each 2 weeks iteration you need to do the whole 5 phases at once (if you can, that’s great — you’re able to follow AGILE way full speed, but it’s not always possible).

All I want to say, is that in my mind, it’s too early to write off old good Waterfall project management body of knowledge — it still can serve blended with more progressive AGILE approach in situations when the latter is not practical in its pure form.