Agile vs Waterfall… a few misconceptions revealed

Here's a list of interesting concepts in software development. Now think about it, who do you think might have stated them so clearly?

  • Design for Iteration: each step progresses and the design is further detailed, there is an iteration with the preceding and succeeding steps...

  • Get Feedback:

    If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version..

  • Sharing Knowledge:

    Each and every worker must have an elemental understanding of the system...

  • Centrality of People:

    ..the personnel involved... They must have an intuitive feel for analysis, coding, and program design. They must quickly sense the trouble spots in the design, model them, model their alternatives, forget the straightforward aspects of the design which aren't worth studying at this early point..

  • Code Review:

    ..every bit of an analysis and every bit of code should be subjected to a simple visual scan by a second party..

  • Automatic Tests:

    ..every logic path in the computer program at least once with some kind of numerical check.

  • Involve Customers: is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.

Who said that?

I'm afraid these words are not the result of your favourite Agile programming guru. Quite the opposite.

These are all sentences taken from the 1970 paper considered to be the manifesto of Waterfall design paradigm. Oh yeah. (it's called Production of Large Computer Programs by Herbert Benington).

How's that possible? Agile, Scrum, Waterfall.. it's like a war among 'philosophical' schools, each one promoting a different solution to the dilemma of how to achieve the most efficient software development process. In reality, there is often a big difference between what's been proposed originally, and what people make of it in the years.

That's the main thesis of an inspiring keynote talk by Paolo Perrotta (italian only I'm afraid). Essentially, what he suggests is that waterfall wasn't that evil after all. But waterfall has had success, and as a consequence of that it sold out. Or better, it's been emptied from its original ideas and principles, and modified and misinterpreted so to cover for a multitude of usage scenarios and personal preferences. So, Perrotta warns us, we should recognise that the same is happening with Agile: its massive success is leading to the transformation of its principles into empty buzzwords, of its core functions into roles that are often played by people according to predefined scripts and with little understanding of its core ideas, which, at the end of the day, presuppose one central tenet: being reasonable.

Thanks Paolo for these thought-provoking ideas (and tx to Enrico for mentioning it to me)!

Cite this blog post:

Michele Pasin. Agile vs Waterfall… a few misconceptions revealed. Blog post on Published on Feb. 27, 2013.

Comments via Github:

See also: