Waterfalls don’t exist…

“We use the waterfall methodology”. You can literally see the scorn on the developer’s face. No one wants to use the waterfall methodology. Except if you are a project manager, of course. They secretly prefer the waterfall, because it shows progression. All these agile iterations, rework, and daily stand-ups are difficult to fit into the weekly status report – when it is all going to finish?

But here’s the thing. There is no waterfall methodology.

I’m not the first to claim that there never was a waterfall model. Some say Winston Royce described the original waterfall method, but he never used the word waterfall nor did he describe a waterfall like project management approach. It does look like one on page two in his original paper, but the rest of the paper describes all of the recommended iterations and feedback loops. Not very waterfall like. I’ve never been part of a project which used a strict waterfall model. Yes, there was stages which we completed, but there was always iterative reviews, change management and several releases of the software.

And the other thing: Agile methodologies are as much a waterfall as traditional methods (as described by Royce).

All agile methods have a start, a middle and an end. Whether you describe the middle as spirals, iterations or re-factoring activities, they are about bringing the project towards its completion. It is true that agile methods are the opposite to the waterfall model, but that is also true for all other software engineering development methods. It is just not possible to develop software in a strict, waterfall fashion. Software development is a creative activity, not a construction activity. We can of course pretend and just iterate away, but that is a risky proposition. As I have written before, it is really not about agile versus traditional methods.

What really matters is the time it takes to make the right set of decisions.

If you can do it fast then you are agile. If not then… well, you are slower. Agile methodologies are good at making decisions fast. But for larger projects, they lack the structure and overall decision authority. This, I believe, introduces the risk of people being forced to make decisions that aren’t really theirs to make, at the wrong time and without the appropriate context. There is nothing agile about incorrect design decisions; think mud.

Not that traditional methods are much better. They often get in the way of decision-making. So will too many stakeholders, design by committee or a lack of authority delegation.  Process and methodology don’t make decisions, people do. Architecture, process and methodologies help to structure and organise the required work. Agile methodologies, prototypes and general feedback help to evaluate the design at certain points.

But true project agility is only achieved through efficient decision-making; decisions made by authorised people at the right time within an appropriate context. This is why architectural decisions are so important to document and manage.

Good, well-documented architectural decisions makes you agile – even if you like waterfalls.