Extreme Programming Perspectives

The values of XP should be captured in any modern software project, even if the implementation may differ radically in other environments. Communication and simplicity may be stated in other terms (coordination and elegance, for example), but without them, nontrivial projects face almost insurmountable odds. The XP principles of communication and simplicity are fundamental process design principles for organizations using the Software CMM also. When defining processes, organizations should capture the minimum essential information needed, use good software design principles (such as information hiding and abstraction) in structuring the definitions, and emphasize usefulness and usability [Paulk1999]. Rapid feedback is crucial to real-time process control; it has even been captured in previous centuries by aphorisms such as "Don't throw good money after bad," and in the quantitative sense can be considered the soul of Level 4. One of the consequences of the Level 1 to 2 culture shift is demonstrating the courage of our convictions by focusing on realism in our estimates, plans, and commitments.

Much of the formalism that characterizes most CMM-based process improvement is an artifact of large projects and/or severe reliability requirements, especially for life-critical systems. The hierarchical structure of the Software CMM is intended to support a broad range of implementations within the context of the 18 key process areas and 52 goals that compose the requirements for a fully mature software process.

As a system becomes larger, some XP practices become more difficult to implement. As projects become larger, emphasizing a good architectural "philosophy" becomes increasingly critical to project success. Architecture-based design, designing for change, refactoring, and similar design philosophies emphasize the need for dealing with change in a systematic fashion. Variants of these concepts, including architecture-based design and integrated product teams, may be more appropriate in large-project contexts, perhaps in conjunction with XP within teams. In a sense, architectural design that emphasizes flexibility is the goal of any good object-oriented methodology, so XP (with refactoring) and object orientation are well suited to one another. Multidiscipline teams are also problematic because XP is aimed at software-only projects.

The main objection to using XP for process improvement is that it barely touches the management and organizational issues that the Software CMM emphasizes. Putting in place the kind of highly collaborative environment that XP assumes requires enlightened management and appropriate organizational infrastructure. The argument that process discipline in the CMM sense even to the point of a rigorous, statistically stable process is antithetical to XP is unconvincing. XP has disciplined processes, and it is apparent that the XP process is a "well-defined" process. CMM and XP can be considered complementary. The Software CMM tells what to do in general terms but does not say how to do it, while XP is a set of best practices that contains fairly specific how-to information an implementation model for a particular kind of environment. XP practices may be compatible with the intent of a practice (or goal or key process area), even if they do not completely address it.

At Level 2, Requirements Management is addressed by stories, on-site customer, and continuous integration. Software Project Planning is addressed by the planning game and small releases. The XP planning strategy embodies Watts Humphrey's dictum, "If you can't plan well, plan often."

Software Project Tracking and Oversight is addressed by the "big visual chart," project velocity, and commitments (stories) for small releases. The commitment process for XP sets clear expectations for both the customer and the XP team at the tactical level and maximizes flexibility at the project's strategic level. The emphasis in XP on 40-hour weeks is a general management concern that is not addressed in the CMM but is considered a best practice. XP also emphasizes open workspaces, a similar "people issue" that is outside the scope of the CMM. Software Subcontract Management is not addressed by XP (and is likely to be not applicable in the target environment).

Although an independent Software Quality Assurance (SQA) group is unlikely to be part of an XP culture, SQA could be addressed by the culture of pair programming; ensuring conformance to coding standards is a typical SQA responsibility that is handled by peer pressure in an XP environment. However implemented, a CMM-based process has mechanisms for objectively verifying adherence to requirements, standards, and procedures. The XP reliance on peer pressure, although effective in most environments, may be vulnerable to external pressures, and this vulnerability should be considered at the organizational level.

Software Configuration Management (SCM) is partially addressed via collective ownership, small releases, and continuous integration. Although not completely and explicitly addressed, configuration management is implicit in these XP practices. Collective ownership may be problematic for large systems, where communication channels need to be more formalized to be effective, and could lead to SCM failures.

At Level 3, Organization Process Focus is addressed at the team level rather than the organizational level, but the philosophy behind adopting XP one practice at a time and "just rules" implies a focus on process issues. Because XP focuses on the software engineering process rather than the organizational infrastructure issues, this and other organization-level processes are areas that need to be addressed by organizations adopting XP, whether in a CMM-based context or not. Similarly, Organization Process Definition and Training Program are partially addressed by the various books, articles, courses, and Web sites on XP, but organizational assets are outside the scope of XP. As a consequence, Integrated Software Management cannot be addressed, because there may not be any organizational assets to tailor.

Software Product Engineering is well addressed in many ways by the XP methodology with metaphor, simple design, refactoring, the "mothball" tour, coding standards, unit testing, and functional testing. The lack of design documentation would be a concern in many environments, such as hard real-time systems, large systems, or virtual teams. In such environments, good designs are crucial to success, and the refactoring strategy would be high risk. For example, refactoring after a system has been proved to satisfy hard real-time requirements by a technique such as rate monotonic analysis would mean that the analysis would need to be redone the assumption that change does not have a high cost would be invalid in such an environment.

Intergroup Coordination is addressed by the on-site customer and pair programming. XP's emphasis on communication appears to result in as comprehensive a solution to intergroup coordination as integrated product and process development (and could be judged an effective IPPD approach), although the software-only context ignores multidiscipline environments.

Peer Reviews is addressed by pair programming. Pair programming may be more powerful than peer reviews, in the sense of code reading and literate programming, although the lack of structure may lessen its effectiveness. The empirical data on pair programming is currently sparse but promising [Williams+2000]. Contrasting and comparing pair programming and peer review techniques remain an area needing empirical research as a basis for making informed trade-off decisions.

Few of the Level 4 and 5 key process areas are addressed by XP in a rigorous statistical sense, although Defect Prevention may be partially addressed by feedback during rapid cycles. Potential satisfaction of CMM key process areas by XP is summarized in Table 42.4, at least within the appropriate domain for XP.

Many of the key process areas partially covered or not addressed in XP are undoubtedly addressed in real projects. XP cannot survive without management and infrastructure support, even if it is not explicitly called out. It seems fair to say that XP focuses on the technical work, where the CMM focuses on the management work, but a concern with "cultural issues" is evident in both.