Note: CMM is a service mark of the Software Engineering Institute at Carnegie Mellon University.
Shawn Presson, Director of Organizational Practice, ITS Services, Inc. says:
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? ...
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...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.)... (See full text)
Ken Schwaber of the Agile Alliance responds:
Reading Shawn Presson’s comments regarding CMM, waterfall, and agile reminded me of Barry Boehm’s comments at XP/Agile Universe’02 and the comments of several CMM authors at INCOSE’02. I was reminded of the good intentions and sound footings of CMM and Waterfall, both initiated to address problems in systems development and systemic project failures rates that have only marginally improved over the decades...
...CMM, waterfall spring from a different theoretical basis than agile processes. Increased precision and definition are at their core, which is one of the alternatives for controlling a process. However, this approach only works when the definition and the problem have a mapping approaching 1:1 and the problem domain (technical, requirements, and people) is relatively simple: “It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.” Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992.
The agile process is based on the empirical approach, accepting the complexity of the problem and addressing it through frequent inspection and constant adaptation...Empiricism is seen even in the Agile Manifesto, where the signatories pose agility as an empirical counterpoint to a defined approach, rather than as a new set of defined absolutes. The various agile processes implement empiricism with the underlying practices of iterative development, frequent inspection of status and increments of work, self-organizing teams, emerging architecture and requirements, and solid collaboration... (See full text)
English 
French 
Spanish