(c) Vince Alcalde (11.28.2017):
“(Part Parody. Part Not. What a Die Hard Waterfall Enthusiasts’ Manifesto might Look like)

We have uncovered the better way of developing software by having done it and continuing to do it over many decades.

Through this work we have come to value:

Estimating over No Estimating
Scheduling over No Scheduling
Requirements over No Requirements
Big designs over No Designs
That is, because there is probably no value in the items on the right, we value the items on the left more.

Waterfall Principles
Our highest priority is to satisfy the customer through delivery of valuable software on budget, on schedule, on spec.

Welcome changing requirements, even late in development. A change control process lets you weigh the cost of the change versus the benefits, so only cost-beneficial changes get through , saving you from yourself.

Deliver a working production software once at the end. There is no point in delivering half-baked bread – it won’t taste the same as the final product.

Business people and developers must work together throughout the project. (The Agile Manifesto did not invent this)

Run projects utilising motivated and expert individuals and teams. Give them the environment,schedule, budget, information, and support they need, and trust (and track) them to get the job done.

The most efficient and effective method of conveying information to and within a development team depends on the context.

Achievement of milestones and Earned Value are the primary measures of progress.

Waterfall processes promote sustainable development. The teams doing the actual work only work in one or two phases of the project, never all, so they don’t burn out.

Continuous attention to technical excellence and good design enhances non-turbulent flow of work.

Documentation – the art of recording information so it’s permanently available in the future – is essential.

The best architectures, requirements, and designs emerge from the best architects, analysts, and designers.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. (The Agile Manifesto did not invent this).”