Through twitter I came across this chapter in Dean Leffingwell's book Scaling Software Agility. This is another example of poor references to old processes and the mis-understanding of how software development processes work in domains (possibly) outside ones own experience. In this case DoD procurement methods versus commercial internal software development.
There are certainly problems in all software projects, no matter what development being used. But when thought leaders produce stuff like this is dilutes the credibility their message when that message needs to be increased.
Here's the starting point. This is the Water Fall paper from 1970. 1970 for gawd's sake. How about a development method for 1980, 1990, 2000, or maybe even 2011? The type of development defined in the 1970 paper is not allowed in the domain the Waterfall paper was created in. 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 was 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 and we had incremental and iterative processes for embedded station holding software in place already. Dean says in the book, this model was never to used ... but now that you're using this model, here's the problems. This is like the news reporter asking the Senator when did you stop beating your wife? It's a bait and switch argument. Poor understanding at best, manipulation of the problem at worse.
Next comes a really bone headed picture. This shows the deadline moving to the left. This violates the Federal Acquisition Regulation (FAR) and the Defense Federal Acquisition Regulation (DFAR). You cannot move anything on baseline without adjustments either by re-baselining or single point adjustments the program.
It's not allowed. It's a baseline. It's "against the law." Moving to right many times happend. Moving the left is complete nonsense in the domain Dean describes these diagrams came 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 Figure 2-3 being completly bogus, the rest of the chapter is tainted with naive and misunderstood processes as well.
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 don't know the rules of the domain where Waterfall is sourced.
- They don't know the history of the domain.
- They do know their own domain and history, but haven't asked people from other domains about the validity of their materials.
- The book has poor copy editing.
In all cases there are two down sides.
- The need for improved software development processes is present in ALL domains. But in the domain I work, where budgets run arond $80B for IT alone, and many many 100's of millions for embedded solutions, when I see stuff like this I wonder what else is not understood.
- With the advent of NDAA Section 804 initiatives, we need credible voices on deploying better agiltiy in our structured and many times over structure procurement world. When books like this, voices stating EV is of no value to IT programs, mis quotes of MIL-STD's, and general misunderstanding of how complex systems are designed, developed, deployed, and managed, those very voices are reducing their credibility.
Some how, some way, those with possible solutions need to gain some level of understanding of how large complex system of systems are developed and stop making these nonsensical examples of how to manage projects badly. It's like Men Behaving Badly, a 1996 -1997 sit-com where the characters do really stupid things and people laugh. The show was canceled part way through the second season for all the right reasons - it was a bad show. Just like doing things shown in Figure 2-3 is really bad project management.
Please Make It Stop
