-----Original Message-----
From: Shawn Presson [mailto:spresson@itssinc.com]
Sent: Thursday, August 15, 2002 2:59 PM
To: jeff.sutherland@computer.org
Cc: kassetc@aol.com; marysze@aol.com; bjgispi@aol.com
Subject: Waterfall methodology
Quote from the web site - "Waterfall methodology - Requirements, analysis, design, development, and implementation is executed as a single linear process. This is no longer recommended even for conventional projects because of the typical poor results caused by unexpected events during the development cycle."
Why, why, why does everything think the waterfall life cycle is exclusively linear? It was designed to be extremely iterative, it allowed for the fact that there may be parallel, non-sequential sets of requirements under development (hence multiple, simultaneous "waterfalls"), it in no way assumed that requirements will be static during a project. It was only after the DoD got its hands on it that this interpretation of the model came about, but why are we listening to the DoD on something like this? Subsequent life cycles (spiral, iterative, and so forth) carry out the same basic, potentially highly recursive activities of the waterfall life cycle, they just do it in a very tight and rapid manner. Yes, some of the phases happen concurrently or even apparently out of order. The original authors of the waterfall life cycle description would be ok with that, just so long as there was method to the madness.
Why, why, why do we assume that "repeatable" and "defined" models preclude emergence? These terms are obvious reference to the CMMs, but the CMMs don't lock you into waterfall, spiral, or any other life cycle or methodology. With reference to requirements, the CMM says, "don't let your junior developer bet the farm on meeting a requirement that the project doesn't know about." Does SCRUM cover this point? Great, then SCRUM is the METHOD whereby this important principle (NOT "process") contained in the model is carried out. With reference to planning, the CMM says, "don't take on a task without reasonable knowledge you have the wherewithal to carry it out." Do you have to have 100% planning accuracy? NO! But if you don't know, then KNOW you don't know, and make that clear in your commitments to your clients. Does SCRUM enable that? Fine! Then SCRUM (or JAD, or whatever) is the METHOD whereby your company avoids inadvertently lying about its capabilities (which is what the CMM planning is largely about, anyway.)
I read Chaos theory before I ever heard of the CMMs, and it was immediately obvious to me that the CMMs could be adapted to the success criteria of the project at hand. Where determinism was critical (shuttle launch program, for example) then the CMM could be interpreted in a deterministic light. Where adaptability is critical, then the model can be used as a checkpoint for certain practices critical to adaptive approaches. HEY, EVERYBODY, QUIT LISTENING TO THE PEOPLE WHO SAY THE CMMs ARE ONLY ABOUT OPERATIONAL EFFICIENCY! There seems to be a popular opinion that the CMMs were written by a bunch of otherwise ignorant egg-heads that came straight from a computer science class. This just ain't so. I have worked for three Software CMM (SW-CMM) original co-authors, and I from them I constantly heard quotes from Juran, Weinburg, Mandelbrot, Crosby, Brooks, DeMarco, Lister, Block, Katzenbach, Peters, etc. etc. In other words, the best industry knowledge was used as a balance, a filter, when evaluating how a CMM-described principle could be applied in a given situation. Many of the original works cited as sources of agile methods were written long before the CMMs, and I can guarantee that most (if not all) of them had been read by members of the SW-CMM team and had influenced the model's development. Many of these concepts were alluded to in the SW-CMM, and have been made more explicit in the CMMI.
The bottom line is that, trying to take a CMM and cram it into an "estimating," "project control," or "operational efficiency" box is very short-sighted. Once again, we can blame this largely on DoD interpretations of the model being touted as the only valid interpretations. I suspect that many authors of current literature are fully aware of this, and simply are capitalizing on selling books to the youth market. It gets funny when I see the word "extreme" tacked onto some practices (such as JAD) that have been around for years (see ComputerWorld, July 22, 2002 "Taking Projects to the Extreme.") But I digress, let's revisit the idea of oversimplification.
Imagine walking into a $250,000 craftsman's shop, opening a toolbox, pulling out a hammer, and declaring based on that sample that all shop tools are only good for driving nails. This is the kind of thing that I see "Agile" proponents doing all the time, and it would be funny if it weren't so shameless. These individuals would be outraged (until they realized that controversy stirs publicity) if I were to go around declaring in public forums that agile methodologies are just a cover for the practice of transferring all risk to the client, enabling the development organization to avoid all responsibility for crappy, negligent work. The fact is, I embrace agile methods, and it is fun to see how they can carry out and support the basic principles of the maturity models. Many of the agile guys, on the other hand, pretend not to understand the distinction between "model" and "method," and I have come to realize their primary motivation is to sell books.
Going back to the waterfall method, the original authors of this life cycle did not intend to demand irreversible, locked-down handoff of work products from one phase to the next. They allowed for requirements change, discovery, reversal, and discontinuation. What they were attempting to do was bring an underlying knowledge of what happens in the development life cycle to avoid out-of-control changes that can make a project degenerate into hack-and-ship exercises where panic de-scoping is the norm, and quality is that thing you sacrifice to meet stupidly insane (often arbitrary deadlines.) The CMMs are about the same thing. Agile methods are about doing it faster. It's time to cut out the "either-or" fiction.
Regards,
Shawn Presson
Director of Organizational Practice
ITS Services, Inc.
703.644.6433fax 703.644.6435
www.itssinc.com