The discussion to abounds about 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 know of no client that has a Program Management Guide that uses “waterfall,” approach – one in which there is no feedback, no adaption of the future from the past – the conventional Design, Code, Test, Deploy cycle in the absence of feedback loops. All are based in incremental evolutionary product development processes. IT has lots of catching up to do.

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

http://www.smawins.com/DoDI_50002_SynImp19Mar09.pdf

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

http://www.corrdefense.org/Key205000-2.pdf

Here’s a summary from INCOSE as well:

http://www.incose.org/chesapek/Docs/2009/Presentations/2009_03_18_Martin_DoDI2002_update.pdf

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 with incremental, iterative, spirals.

So what’s the issue here and why is this 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.

Source: Herding Cats