Teoricamente, o CMMI (Capability Maturity Model Integration) é muito diferente da XP e de outras disciplinas de programação ágeis. Isto também é verdade até certo ponto quando se passa à prática, uma vez que quem já aderiu ao CMMI e às metodologias ágeis aborda tipicamente o desenvolvimento de software a partir de pontos de vista claramente diferentes. No entanto, ao mesmo tempo, os especialistas afirmam que as duas abordagens são surpreendentemente complementares, e que existe muito pouco (se é que existe alguma coisa) de inconciliável entre os dois paradigmas.
Os defensores das metodologias ágeis gostam de argumentar que o problema com o CMMI reside no facto de assumir que o desenvolvimento de software envolve processos explícitos. Ou seja, processos sobre os quais quase tudo é conhecido. No entanto, isso raramente se verifica, como poderá afirmar qualquer programador ágil que alguma vez tenha trabalhado num projecto de desenvolvimento, de qualquer dimensão.
Existe no CMMI a ideia fundamental de que os processos podem ser repetíveis, e que são processos previsíveis - basicamente, não são processos empíricos. Segundo Michael Spayd, da Cogility Consulting Solutions, este é um erro fundamental do CMMI, e está na base da razão porque o mesmo não acredita nos níveis quatro e cinco. Spayd afirma mesmo que esses dois níveis são "ridículos e não acrescentam valor".
Este especialista transitou há vários anos da avaliação de processos CMM para a programação ágil, começando com a XP. Actualmente, afirma que quer ajudar as organizações de TI (tecnologias de informação) ágeis a trabalharem dentro dos limites impostos pelo CMM, CMMI e metodologias similares. Recorde-se que o CMM esteve na base do CMMI.
Spayd é de opinião que os dois paradigmas (metodologias ágeis e CMMI) não são tão inconciliáveis como os partidários de ambas as partes poderão acreditar. Isto, apesar de ser certamente verdade que, em termos culturais, o CMMI vive mais facilmente numa cultura de controlo, em que a ideia é minimizar o risco através da enfatização de resultados previsíveis e repetíveis.
Ao mesmo tempo, Spayd sublinha a opinião de Mark Paulk, um dos autores do CMMI, para quem os dois paradigmas são, de facto, compatíveis. A chave para isso está em considerar o CMMI como uma framework de gestão que descreve boas práticas testadas na realidade, mas que não prescreve uma metodologia específica de desenvolvimento de software.
É verdade que muitas organizações seguem um caminho orientado a processos para implementarem o CMMI. No entanto, não tem que ser dessa forma. Spayd é de opinião que o CMMI não exige uma abordagem em cascata, nem uma abordagem de tipo framework, nem documentação intensiva. Culturalmente, existe uma preponderância dessas práticas, mas não existe qualquer razão para não se utilizarem práticas ágeis para alcançar os mesmos resultados.
Hillel Glazer, um especialista em avaliações CMMI SCAMPI e avaliações ISO, concorda com este ponto de vista, sublinhando que são muito poucas as pessoas do mundo do software que fazem a distinção entre um método ou processo de gestão e um método ou processo de desenvolvimento. Uma vez feita esta distinção, a separação entre a XP e o CMMI torn-se muito mais clara.
Glazer, tal como Spayd, acredita que o CMMI e as disciplinas de programação ágil, como a XP, são complementares, e não inconciliáveis. Mas será que existe sobreposição? Sim, mas isso deve-se sobretudo ao facto da XP incluir elementos de gestão e de desenvolvimento. Quando a XP se aventura nos métodos de gestão, não é incompatível com o CMMI. Não é assim tão invulgar conseguir a certificação CMMI utilizando práticas ágeis, mas isso depende muito da orientação da pessoa que faz a avaliação.
Baseado num artigo com o título "Agile Programming and the CMMI: Irreconcilable Differences?", da autoria de Stephen Swoyer, publicado no site http://www.adtmag.com/.
Produzido em 2008