Waterfall? What Waterfall?

The discussion still abounds comparing Agile Software Development methods with Waterfall. There is absolutely no doubt that some, if not many, IT shops still plan their project in a "Waterfall" style manner.

But my sense is the agilest confuse speaking about the writing of software at the lowest level of the program activities – that task level in the IMS - while using the term "waterfall" at the programmatic management processes of a program.

I also know from daily practice that even in the highest ceremony business of all - US DoD Defense Acquisition - the traditional vision of a "Waterfall" project management method is long ago dead and in the ground.

So why this "red herring" as the basis of discussion? Can't really say. But I can say what is current practice in the domain in which we work.

The current DoD 5000.02 guidance eliminates the term "spiral" (used in 2003) and replaces it with "evolutionary acquisition."

Here's a quick assessment of the new impacts of .02

A Short Survey of the Current DoD 5000.02 Processes

The spiral development process was directed in 2003 through DoD 5000.2 along with incremental.

Another Short Overview of 5000.02

Here's a summary from INCOSE as well:

A Slightly More in Depth of How Programs are procured under DD 5000.02

Especially look at Page 13 of the INCOSE brief

Looking at individual service guidance - NAVAIR for example - the topologies found in waterfall - linear acquisition - were replaced a decade of so ago with incremental, iterative, spirals.

So what's the issue here and why is this conversation important?

1. When we have a discussion about development methods and confuse them with Program Management methods, neither side of the discussion is informed.
2. Confusing software development methods with project management methods, removes a large percentage of the work activities for a project from the conversation and possibly from the project, leaving the project open to risk. Wanna answer why project fail. Look at the real statistics - Poor Planning and Controls. No Requirements Management, No measure of Physical Percent Complete - Agile does shine here.
3. The context and domain of many development methodologies is just that "the development of software" - code. No the management of the program. Round Peg Square Hole.

In the end providing a Value Proposition of Agile has served us better than comparing Agile to some mythical obsolete method no longer allowed in the DoD. Tell me "why" I should use something, not "why" the old way is bad.