Yet Another Bad Example of Using or Misusing the Waterfall Paradigm

Through Twitter, I came across Dean Leffingwell's book Scaling Software Agility. This is another example of poor references to old processes and the misunderstanding of how software development processes work in domains (possibly) outside one's own experience.

In this case, DoD procurement methods versus commercial internal software development.

There are problems in all software projects, no matter what development is used. But when thought leaders produce stuff like this, it dilutes the credibility of their message when that message needs to be increased.

Here's the starting point.

This is the Water Fall paper from 1970. 1970, for god's sake. How about a 1980, 1990, 2000, or even 2011 development method? The type of development defined in the 1970 paper is not allowed in the Waterfall paper's domain. And, if the thought leaders would read the paper and stop clipping pictures from the paper (which Dean did a bit before going back to the Red Herring), they would find out that Walker was stating that this approach gave poor results for TRW's effort.

I never met Dr. Royce, but I worked in Building O-6, One Space Park, during a later period (1980) of his tenure. We already had incremental and iterative processes for embedded station holding software. Dean says this model was never to be used in the book, but now that you're using it, here's the problem. This is like the news reporter asking the Senator when you stopped beating your wife. It's a bait-and-switch argument—poor understanding and manipulation of the problem.

Next comes a boneheaded picture. This shows the deadline moving to the left, which violates the Federal Acquisition Regulation (FAR) and the Defense Federal Acquisition Regulation (DFAR).

You cannot move anything on the baseline without adjustments, either by re-basing or single-point adjustments to the program.

It's not allowed. It's a baseline. It's "against the law." Moving to the right has happened many times. Moving to the left is complete nonsense in the domain Dean describes these diagrams as coming from. If you do that on a commercial project, you get what you deserve—a failed project.

That means Dean's example is not allowed; it's a non-starter. With Figures 2-3 completely bogus, the rest of the chapter is tainted with naive and misunderstood processes.

So why do the agile thought leaders do this nonsense?

I can't say, I haven't asked them. But here's some wild speculation:

• They need to learn the rules of the domain where Waterfall is sourced.
• They need to learn the history of the domain.
• They know their domain and history but have yet to ask people from other domains about the validity of their materials.
• The book needs better copy editing.

In all cases, there are two downsides.

1. The need for improved software development processes is present in ALL domains. But in my domain, where budgets run over $80B for IT alone and hundreds of millions for embedded solutions, what else is not understood when I see stuff like this?
2. With the advent of NDAA Section 804 initiatives, we need credible voices to deploy better agility in our structured and, many times, over-structured procurement world. When books like this, voices stating EV is of no value to IT programs, misquotes of MIL-STD's, and general misunderstanding of how complex systems are designed, developed, deployed, and managed, those very voices are reducing their credibility.

Those with possible solutions need to understand how large, complex systems are developed and stop making nonsensical examples of how to manage projects badly. It's like Men Behaving Badly, a 1996 -1997 sitcom in which the characters do stupid things, and people laugh. The show was canceled partway through the second season for all the right reasons—it was a bad show. Doing things shown in Figures 2-3 could be better project management.

Please Make It Stop