One dimension is discipline and the other, entrepreneurial attitude, or in our context, agility. If one has strong discipline without agility, the result is bureaucracy and stagnation. Agility without discipline is the unencumbered enthusiasm of a startup company before it has to turn a profit. Great companies have both in measures appropriate to their goals and environment. (Location 404)

The agilists rail against the traditionalists and lament the dehumanization of software development by “Taylorian” reductionists who worship process. The establishment has responded with accusations of hacking, poor quality, and having way too much fun in a serious business. True believers on both sides have emerged to proclaim their convictions with near-messianic stridency, raising the perplexity level of software developers and managers trying to evolve their success strategies. (Location 441)

Probably the easiest source of perplexity to identify, and perhaps the most difficult to resolve, is that of multiple definitions for the same word. For example, the term disciplined, whose dictionary definition includes both “common compliance with established processes” and “self-control,” is confined to process compliance by CMM bureaucrats, and confined to self-control by agile free spirits. Similarly, agility has been selectively interpreted positively as “dexterity” and negatively as “inconstancy of purpose.” A further example is quality. In the SW-CMM, “quality assurance” is defined as “specification and process compliance.” Agile methods see quality as essentially customer satisfaction. (Location 453)

An excellent example of overdisciplined bureaucracy was a picture of the “CMM Level 4 Memorial Library” recently exhibited by an aerospace company. It showed bookcase upon bookcase of 99 2-inch binders containing evidence of SW-CMM Level 4 process compliance. These were not produced to help the project, but to pass an external appraisal required to obtain an authorized CMM Level 4 rating. (Location 469)

It is easy to assume universality when we find something that works. This is the essence of a silver bullet, whose life cycle has been delightfully described by Sarah Sheard of the Software Productivity Consortium as a journey through discovery, successful application, publicity of success, momentum building and publication, first (slightly modified) replication, confirmation by early adopters, proceduralization and implementation in disparate environments by uninformed middle management, insufficient funding and misapplication, diminishing returns due to devolution of original idea, denigration of the original idea, and ultimately demise and new discovery. (Location 481)

Plan-driven methods are generally considered the traditional way to develop software. Based on concepts drawn from the mainline engineering fields, these methods approach development in a requirements/design/build paradigm with standard, well-defined processes that organizations improve continuously. (Location 516)

The definition and management of processes is key to plan-driven methods. For that reason, plan-driven methods are almost always associated with process improvement. The processes need to be defined, standardized, and incrementally improved to provide the data needed to control and manage their operation. Such processes generally include detailed plans, activities, workflow, roles and responsibilities, and work product descriptions. The people who perform them must be trained in their application, and there is often a group of individuals who act as the process monitoring, controlling, and educating infrastructure. Figure 1-1 illustrates an example of process management. (Location 538)

Management must understand that processes are vital to the delivery of the product, and that circumventing them can add significant cost and schedule risk. The infrastructure for plan-driven processes includes process asset libraries that encourage process reuse, process training for practitioners, and usually a process management staff that supports the maintenance of process documentation. (Location 579)

Some amount of individualism must be forfeited in the maintenance of a prescribed process, but often creativity must be used in adapting the process to the vagaries of the project as it progresses. (Location 587)

Rational's Philippe Kruchten has likened the CMM for Software to a dictionary; that is, one uses the words one needs to make the desired point—there is no need to use (Location 682)