J’en viens à me dire que pour faire de l’agilité sur un projet, il faut renoncer à appliquer une méthode agile précise. Même si le principe défendu par tous les agilistes est de commencer par appliquer les techniques « officielles » afin de monter en compétences dessus avant de vouloir les changer.

Ceci étant dit, il convient de s’adapter au mieux à la réalité du projet : personnalité de l’équipe, historique commun ou non, expérience des uns et des autres, …
En particulier renoncer à avoir une norme agile au niveau de l’entreprise.

Cela revient à opposer agilité et CMMI : définition d’une norme, respect de cette norme, optimisation basée sur des statistiques sur les autres projets, …
Sauf à identifier au niveau CMMI un certain nombre de pratique, leur domaine et conditions d’application, les dérogations possibles, les interdépendances (pas de campagnes de refactoring sans tests unitaires automatisés,…)

Si CMMI est la norme, s’il faut expérimenter et quantifier pour adopter, eh bien allons y. Expérimentons et quantifions.

Et soyons souples sur le terrain, en « oubliant » peut-être de préciser tous les détails d’implémentation lors des revues CMMI…

Peut-être que pour finir de se généraliser, l’agilité devrait renoncer à son nom. Pousser les pratiques en faisant appel au bon sens, unitairement, au lieu de faire un agile big bang. Le but n’est pas d’avoir 100% des projets estampillés agiles. Le but est d’améliorer 100% des projets pour qu’ils atteignent leurs objectifs métier. Ne pas renoncer non plus à l’évangélisation, mais essayer de ne pas faire trop peur.