Agilité, quelle Agilité ?

Ces trois dernières semaines, trois clients nous ont demandé une méthode pour répondre à leur besoin de déploiement d'un projet CRM ou BI dans un délai court et mettre en production une application Microsoft nouvelle ou refondue.
Chaque fois le terme "agile" a été utilisé et pourtant j'ai proposé chaque fois une méthode différente, adaptée au contexte du client et à la solution Microsoft concernée. L'agilité est-elle finalement un abus de langage ou bien reflète t-elle une réalité chaque fois ?
En fait, l'agilité repose sur des valeurs et pratiques décrites dans le Manifeste Agile en 2001 dont voici les principes que je partage totalement : 

• livrer fréquemment et régulièrement le logiciel ;
• faire des cycles de développement courts et limités dans le temps ;
• constituer une équipe complète (experts Métier, développeurs, ...) ;
• gérer les membres de l'équipe en les responsabilisant (choisir des membres motivés) ;
• avoir le représentant des utilisateurs sur le même site que le reste de l'équipe ;
• rechercher la simplicité, l'alignement avec la solution ;
• rester attentif à l'amélioration de la façon de travailler en cours de projet ;
• rester attentif à la qualité du code ;
• écrire les tests avant les codes.

(Un grand merci à Claude AUBRY et à son ouvrage SCRUM qui apporte un excellent résumé des pratiques et donne matière à réflexion)
Ainsi, dans le projet BI (refonte du modèle de données, du cube, des reports et des packages d'intégration), je mets en place une méthodologie de développement et de qualification par cycle court (pas plus de 2 semaines) à partir de lots fonctionnels cohérents et progressifs.
Pour le premier projet CRM, je propose une méthode déjà éprouvée plusieurs fois avec MS Dynamics CRM : la proposition d'un modèle de données et la présentation d'une maquette puis des ajustements successifs avec les utilisateurs.
Dans le second projet CRM où il s'agit cette fois de reprendre un projet en cours de route, je sécurise la recette et la mise en production sur les fonctions clés en accompagnant le client sur cette phase délicate. Puis j'accompagne les utilisateurs plusieurs semaines de suite pour faire évoluer la solution au même rythme que leurs besoins marketing émergent.
Dans tous les cas, le chef de projet doit disposer d'une double compétence fonctionnelle, technique associée à son expérience du pilotage, pour savoir dialoguer et réunir tous les interlocuteurs. Pour favoriser l'esprit de groupe, assister si besoin et fournir les moyens de travailler.
Cette méthode est efficace et correspond à la demande du marché. Selon moi, elle exige néanmoins des compétences avérées et la motivation de chacun. En ce sens, elle peut se révéler difficile et échouer si l'équipe est mal construite ou ne s'accorde pas.
Note : je ne partage pas tous les principes, ou du moins certains ne me semblent pas forcément applicables dans les solutions Microsoft que je porte.