Accidental Waterfall

Carving boundaries between teams almost always carves technical boundaries into the same ground. This means where you divide teams is a technical design decision – it has an impact on your architecture and all design that follows.

These boundaries can be difficult to reevaluate because it is no longer only a technical matter. There’s now resistance to change from people within the organisation and the structure of the organisation itself. It can become almost impossible to merge teams together or redefine borders, because this now threatens autonomy, takes away ownership, and dilutes influence.

You could say certain design paths are discouraged. Not necessarily because they are technically difficult to do, but because they would now be unpopular.

No matter how poorly the architecture works, your choices have been restricted. You cannot go backwards from here to reevaluate or iterate. You have fallen down a waterfall.

Isn’t this the essence of what is wrong with the waterfall model of software design? It is sometimes mistakenly blamed on up-front design, but the true problem is organisational barriers preventing change. Each step of a solution must conform to a decision made in a previous step, no matter what you discover along the way or how unsuitable those decisions seem now.

Beneath the acronyms, the consultants and the cargo-culting, what is essentially good about ‘agile’ is iteration.

I doubt we can entirely stop organisational structure or process from limiting design or preventing iteration, but perhaps we can at least stop it from unconsciously growing out of control.

Let’s not pretend we are enlightened and ‘agile’ and that we have left the problems of the waterfall model to the dark recesses of software development history. It still lurks in more subtle forms.

What can’t you challenge? Where aren’t you iterating? Perhaps you are accidentally falling down waterfalls.