If you are into the software development process and may happen to know about SEI's CMM – the Software Engineering Institutes Capability Maturity Model for Software aswell as about Extreme Programming then you will definately …

...have to read the article Extreme Programming from a CMM perspective

It discusses how XP can address many issues of the CMM levels 2 and 3 (which focus mostly on Project Management and Software Engineering repectively) and improve existing processes and uses,

while not everything in XP seems to be good adaptable in CMM - on the first hand.

remember – CMM Level 2 and 3 have the goals

Level 2) Process Repeatable. Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.

Level 3) Process Defined. The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining

and that will sure help for more flexible processes in XP aswell…

If you have no idea what CMM is about, then try to find out about the basics in the following:

• SEI CMM for software with the five process maturity steps explained
• SEI CMM for Software, Systems Engineering, and Product Development (they integrate several models togehter in CMMi, but it remains rather similar)

Extreme programming guidelines and introductions can be found at:

• Extreme Programming
• German Extreme Programming – Frank's german explanation for the lazy "DACH"-reader (german, austria, switzerland = DACH)
• Rules of XP ad handy set overview of rules of XP
• Xprogramming contains Articles, FAQs, and other information on the XP methodology

But I think it's necessary to point out again, the the "freedom" of XP might aswell might be it's doom if the process itself is adapted because of no big up-front design and minimal documentation requirements, but without taking care of the real productivity boosters such as automatic unit testing, pair programming (well good discussions with good peers actually – CMM has something similar in peer-reviews), collective ownership (a real culture change) and constant refactoring (dammit – another set of patches again).

An interesting book against the hypes of Extreme Programming must be:

but I haven't read it yet – checkout this for more..