Conclusion

Most of XP consists of good practices that should be thoughtfully considered for any environment. Although the merits of any of these practices can be debated in comparison with other ways of dealing with the same issues, none of them should be arbitrarily rejected.

Putting these practices together as a methodology may be a paradigm shift in the same sense that concurrent engineering is. The concepts in concurrent engineering have been around for decades; integrating those concepts as a system results in a paradigm shift in how to build products. In a similar manner, XP provides a systems perspective on programming (if not the only one), just as the Software CMM provides a systems perspective on organizational process improvement. Organizations that want to improve their capability should take advantage of the good ideas in both and exercise common sense in selecting and implementing those ideas.

The Software CMM focuses on the management issues associated with putting effective and efficient processes in place, along with systematic process improvement. XP is a specific set of practices a "methodology" that is effective within its context of small, colocated teams. Both have good ideas that can be synergistic, particularly in conjunction with other good engineering and management practices. It is questionable whether XP, as published, should be used for life-critical or high-reliability systems. The lack of design documentation and the deemphasis on architecture would be judged risky decisions by most knowledgeable professionals, but one of the virtues of XP is that it can be changed and improved for different environments.

The risk in changing XP is that the emergent properties providing value in its proper context may not emerge. Still, the emphasis in choosing and improving software processes should be to let common sense prevail and to use data whenever possible to provide insight when answering challenging questions.