Agile ou contortioniste?

Pourquoi la méthode Agile a du mal à s'imposer dans les projets informatiques?
Une réponse intéressante à cette question a été postée sur le site DZone. L'auteur explique que que le client trop impliqué par Agile, se comporte comme s'il ne voulait pas qu'on lui reproche le disfonctionnement de l'application qu'il a contribué à spécifier. Plus crûment, il ne veut pas être blâmé en cas de problème. D'où vient ce sentiment?
Le plus souvent, une solution informatique en entreprise est imposée plus que choisie. Dès lors, elle cesse d’être une solution pour devenir un fardeau. La vision simplificatrice de l’entité « Client » occulte tous les aspects humains entourant la réalisation d'un projet.
Agile est une méthode pragmatique, bâtie sur l’hypothèse d’un monde faillible et d’un contexte humain contraint et donc peu coopératif et peu constructif par nature. Cette méthode a brisé la linéarité irréaliste de Waterfall en petits incréments, dont le but est de faire apparaître les imperfections, le plus tôt possible.
Voici un exemple type d'un dialogue Agile entre Marlene, du service de Gestion et Fred, un développeur:
F: Voici ma compréhension de ce cas d’utilisation. Êtes-vous d’accord ?
M: Oui.
F: Alors passons à la réalisation…. Qu’en pensez-vous maintenant ?
M: Ce n’est pas bon, vous n’avez pas bien compris ce que je voulais dire.
F: Pourtant je l'ai écrit et vous l’avez relu… Recommençons…. Qu’en pensez-vous maintenant ?
M: C’est beaucoup mieux. Il reste deux trois détails
….
M: Là c’est parfait !
Une fois l’application mise sur rails, on se rend compte que ce cas d’utilisation mérite d’être revu. Il faut refaire appel aux service de Fred et Marlene qui avait validé ce cas, risque d’être pointée du doigt et le vivra mal.
C’est de cette situation que souffre Agile. Le fait que le client s’implique à ce point dans le processus de développement et le risque qu’il en soit blâmé. Ceux qu’on doit blâmer, traditionnellement, ce sont les fournisseurs, non ?! Pourtant Marlene ne devrait pas avoir de soucis à se faire, l'éventualité de redévelopper un cas d'utilisation fait partie d'Agile et ne coûtera pas plus chère à l'entreprise.
Agile remet en question les situations schizophrènes comme par exemple: le client ne maîtrise pas son métier et ne peut pas l'admettre et le fournisseur n'a aucun moyen de lui soutirer des informations et ne peut pas s'en plaindre. Alors on fait avec... Une situation Ubuesque qui a mené en deux décennies, à une belle pagaille dans les SI.
Alors on tente de remplacer cela par un processus qui répartit les responsabilités ou, disons, en crée là où il n’y en avait pas auparavant. Une méthode qui tient compte de l'imperfection des hommes et des logiciels pour peut-être moins de stress inutile dans les projets.
Un projet ne peut être quantifié seulement par une durée, un budget et un taux de cas d’utilisations couverts. Il faudrait y ajouter une composante que nous avons totalement occulté : la sérénité.
J. Stiglitz a introduit un indicateur de « bien être » dans l’évaluation du PIB, ce qui révèle que des pays supposés riches ne le sont pas réellement. Pourquoi ne pas en faire autant pour les projets informatiques ? Cela révèlera peut-être que certains projets sont plus aboutis que d’autres, même si la sacro-sainte « deadline » n’a pas été respectée.