Not surprising, as it's his methodology.

My assessment overall is that XP has some characteristics in common with the higher SEI levels, up to and including level 5. However, I would not assert that an XP team is a level 5 team. It takes a lot more documentation and "proving" going on in CMM than we recommend for XP. XP is in some ways a "vertical" slice through the SEI levels 2 through 5.

That's how I saw it. I haven't read the CM paper yet,[1] but to say that agile can take you to Level 3 doesn't make any sense to me.


[1] It hung my browser first time I tried to download it. If I see anything to contradict my impression based on what you said I'll update this.

===

[edit]

That didn't take long.

XP\ufffds critical underlying assumption is that developers can obviate the traditional high cost of change using technologies such as objects, patterns, and relational databases, resulting in a highly dynamic XP process.

Completely wrong. The critical underlying assumption is that the most efficient way to deal with inevitable change is to write the smallest, most useful thing you can, complete it before the requirements change, then write the next most useful thing you can. Use of objects, patterns and RDBMSs are the tactics they have found most useful, but they are not the core concept of XP.

And another:

Refactoring: Restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.

No. You never refactor to add flexibility. Adding something is not refactoring. If you're adding the ability to do another thing in addition to what it already does, you're adding functionality.