The Red herring of Waterfall has risen again as the favorite stalking horse for agilest when trying to find some way to sell their approach. There are several issues with this tactic, not the least of which is Waterfall as described by an agilest is actually prohibited in the government sector. The second issue comes from the favorite reference to the Royce's paper on Waterfall (father and son). Ignore the details of the paper and use it as an example of how Waterfall was pulmigated and still in use. But you need to read the fine print in this paper to discover iterations, customer involvement, "do it twice," feedback up and down the line, etc. etc. For 1970 this was far out stuff.
How It's Done on a Larger Scale Today
The actual top level procurement process for government (DoD) acquisition is an incremental and iterative approach described in the Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management System. Notice all the loops in the "W" style systems engineering process down in the Technical Section. Of course this approach should NEVER EVER be considered outside projects larger than $20M. Of course $20M is chump change in the DoD world. But the point is NEVER NEVER speak of this process in any form when discussing procurement or development process in the commerical world.
But at the same time the Waterfall Red Herring is not allowed even in this world. So why on God's green earth do agile thought leaders speak of Waterfall as the process they are trying to replace. It's simple marketing really. Find the ugliest, least successful, worst track record approach to developing software and use that as your comparison. Never mind that all the "evil" outcomes of the described process are actually BAD Project Management Practices.
In the end ANY project management method - from "magic beans" to DoD IMP/IMS using ANSI-748 Earned Value needs to have an irreducible set of PRINCIPLES on which to base their PRACTICES. Principles and Practices are different. I already spoken to the irreducible principles that can be found in PMBOK
So the question can be asked again. What principles of project management would NOT be found in any credible project management practice? I might suggest Procurement would be one. But I'm stumped to think of any others.
Separating Principles from Practices
So when the latest critique of "waterfall" starts out the discussion rarely if ever is about Principles. It's almost always about practices - and bad practices at that. It's like complaining you can't loose weight while eating Big Macs morning, noon, and night. That !@#$'ing MacDonald's diet just doesn't work. Really? You Think?
Look at the Principles here and ask which ones you would not want in your favorite project management practice. Now the practices can range from back of a napkin, white board or some other favorite media - to a full blown SAP (heavens no, please) based program management process framework.
I might conjecture if you ask and answer the project management process questions in this manner all the "us versus them," the "they were really not very smart in the past," and other opening apporoaches to project management replacements go away. And what you're left with is an assessment of th type of Practices best suited for your domain and context.
