I just finished reading this paper on CMMI and Agile on the SEI site. The authors do an excellent job discussing the "CMMI Model" and how Agile fits well into it. From the paper, speaking on the Agile Manifesto:

The Agile Manifesto is frequently read in such a way that ignores the last line (by too many Agile proponents and detractors alike) and where the "things on the right" (items commonly found in too many plan-driven, contractually-driven, standards, and audit-driven environments) are not merely valued less, they effectively have zero value.

The Agile Manifesto has been frequently cited by Agile proponents as justification for not having processes, for not documenting their work, and for not having plans. This interpretation gives justifiable cause to Agile detractors to accuse proponents of being "undisciplined lackeys." Similarly, Agile detractors abuse the Agile Manifesto by using the same exact mechanism. By attributing a value of zero to the "things on the right," detractors assume the worst of Agile proponents.

However, these interpretations of the Agile Manifesto are incomplete and disingenuous.

At a genuine level of discourse, who wouldn't value the things on the left more than the things on the right? Keep in mind the paradigm from which the Agile Manifesto is trying to depart. Even without researching the discussion among the signers, the source of the Agile Manifesto should not be difficult to guess. In too many implementations there were plans, processes, and standards that were overly detailed, rigid, and just plain abused to the detriment of people, projects, products, customers, and technology.

This speaks to directly to some of what I have posted in the past. We do need process within Agile to be successful in many environments. What that process is varies from team to team. The paper goes on to make the case that both CMMI and Agile have value and can coexist in many environments nicely. Further they authors discuss that fact that software engineering is a human process that involves emotions, leadership, teamwork and respect. Neither of these models offers a panacea for building successful teams. That task is still up to us.