Comment la Gestion Agile peut-elle échouer par la politique de l’autruche ?

Nombre de projets échouent dans leur transition vers l’agilité. Une fois la confiance et l’enthousiasme émoussés, la tentation est grande de revenir en arrière sans comprendre que l’amélioration progressive fait partie intégrante du processus de développement en équipe.

Pour industrialiser l’informatique, le Cycle en "V" a fait long feu

Le principe du Cycle en V est le suivant : un certain nombre d'étapes sont nécessaires pour réaliser un projet informatique. Une partie de ces étapes sont préalables au développement, tandis que d'autres suivent pour garantir la qualité de ces développements. Chacune de ces étapes donne lieu à la production de documentation et, de chaque côté du cycle (descendant et montant), cette documentation fait le lien entre les étapes pré et post codage.

Par Christophe.moustier sur Wikipedia français (Christophe.moustier sur Wikipedia français) [GFDL (http://www.gnu.org/copyleft/fdl.html) ou CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0/)], de Wikimedia Commons

La plupart du temps, deux principaux reproches sont formulés à l'encontre de cette méthode.
Premièrement, le temps passé à rédiger la documentation. Et cette rédaction nécessite l'intervention de nombreuses parties à des moments clefs mais pas à chaque étape du projet. Deuxièmement, et ceci découle de la remarque précédente, les documents produits sont réputés immuables pendant toute la durée du projet et ceci induit un effet tunnel. Or, cet effet tunnel est préjudiciable au projet lui-même. En effet, selon la durée du projet, il est plus que probable qu'entre la rédaction du sacro-saint Cahier des Charges et la livraison, quelques changements interviennent dans l'environnement cible de l'application. Ou que de nouvelles contraintes techniques (internes ou externes) apparaissent, contraignant l'équipe de développement à revenir sur les fonctions escomptées.

L'utilisation de documentation étant intensive, le processus de développement en devient assez rigide. Les membres des différentes équipes auront tendance à s'appuyer exclusivement sur les spécifications publiées, comme d'un rempart à la critique. Cette pratique les amène à se "désimpliquer" du but ultime du projet : répondre aux besoins des utilisateurs finaux, y compris en termes de performances et, surtout, d'évolutivité.
Trop de projets ont mal tourné, malgré MS-Project© ; échouant à répondre aux attentes dans les délais (et donc les coûts) impartis.

Les méthodes agiles cherchent à tenir compte de l’humain

On s'est aperçu depuis la mise en place du Cycle en V que les équipes de développeurs sont faillibles. Elles peinent notamment à tenir un rythme. On voulait industrialiser la production de logiciels et, pour cela, créer des chaînes de montage (regardez bien à nouveau le schéma du Cycle en V ci-dessus et pensez bien fort aux usines Ford, au Taylorisme). Malheureusement, l'humain est inconstant. Et les groupes d'humains le sont encore plus.

Quelques acteurs de l'industrie logicielle ont donc décidé de se réunir pour réfléchir à leurs conditions de travail. Cette réflexion a donné naissance à un Manifeste Agile qui a permis, avec les outils de l'eXtrem Programming (XP) d'imaginer une autre manière de travailler, en s'appuyant sur les personnes plutôt que sur la documentation, les contrats et la planification à long terme.
Au cœur de ces concepts se trouvent le Cycle Itératif et Incrémental ainsi que l'Intégration Continue. Rapidement résumé, on s'appuie sur des livraisons fréquentes, la possibilité de changer les priorités, le partage de la vision du projet (objectifs et avancement) et la collaboration entre les parties prenantes.

Par Vickoff (Travail personnel) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)], via Wikimedia Commons

Pour ce faire, la méthode agile la plus populaire (?) définit par exemple plusieurs rôles au sein de l'équipe projet :

Le Product Owner (PO) est le garant de la vision du projet, il administre la liste des fonctions à délivrer (product backlog), sous une forme synthétique que l'on appelle des Stories
Le Scrum Master (SM) est l'animateur de l'équipe qui s'assure de la distribution des tâches et du rythme de développement, par exemple en fournissant un support d'architecture et de programmation
Le Developer est réputé polyvalent ; certains développeurs expérimentés sont appelés des Champions (c'est toujours bon pour l'égo)
Le StackHolder est un acteur externe au développement mais qui suit l'avancement du projet ; il peut s'agir d'utilisateurs finaux, ou de responsables hiérarchiques par exemple

Les méthodes Agiles comme Scrum (donc) organisent le développement en suivant des cérémonies et des bonnes pratiques (pair programming, TDD, etc.).
Des échanges journaliers (la plupart du temps matinaux et COURTS) appelées scrums, assurent que l'information est bien partagée entre les membres de l'équipe et permettent de détecter les problèmes éventuels.
Une cérémonie de lancement d'un Sprint (quelques semaines de développement) permet d'évaluer la charge de travail nécessaire pour réaliser les fonctions (user stories) jugées prioritaires et préciser la vision du Product Owner à l'instant présent. En fonction de l'estimation donnée par les développeurs eux-mêmes, le PO peut décider de revoir l'ordre de ses priorités.
A la fin d'un Sprint, l'équipe organise une Sprint Review (démonstration) des fonctions implémentées à l'intention de toutes les parties prenantes ; ceci afin de valider la direction prise par le projet.
Enfin, des Rétrospectives permettent de faire un point régulier sur les problèmes rencontrés, qu'ils soient techniques ou méthodologiques, et d'ajuster le fonctionnement de l'équipe pour en améliorer le rendement.

C'est grâce aux Sprints (courts et intenses) que l’adaptation au changement est rendu possible dans les méthodes agiles. On supprime ainsi au maximum l'effet tunnel décrié dans le Cycle en V et l'on minimise le coût éventuel d'un retour en arrière. La documentation pléthorique et contractuelle est remplacée par le dialogue et la négociation. Les développeurs sont amenés à confronter leur travail à une vision élevée de l'application et à la réutilisation de leur propre code au sein de l'équipe.

Mais cela ne suffit pas toujours face aux impératifs de production

Je vous jure que c'est vrai, il y a des équipes de recette qui n'utilisent pas le Cahier des Charges pour effectuer leurs tests à la fin du Cycle en V. On a, par exemple, convié l'équipe de recette à participer aux réunions de préparation et elle se base sur son propre recueil de besoins pour effectuer sa mission, se réservant le droit d'interpréter ce que devrait être le produit fini. Cela se termine en général en pugilat, voire en guerre de tranchées, entre des équipes de développement et de test devenues ennemies farouches, communicant par l'intermédiaire de billets plus ou moins secs dans le bug tracker. Avec des remarques du genre « C’est quel mot que tu comprends pas ?! »). Bref.
Et il y a aussi des équipes "Agiles" qui n'ont pas de Product Owner. Elles fixent elles-mêmes les priorités, voire alimentent le backlog de produit en fonction des demandes faites sur un coin de table par un StackHolder (le plus souvent faisant figure d'autorité... hiérarchique) qui passe de temps en temps dans l'open space "voir comment ça avance" (pour lui). Il y a également des équipes qui sont débordées par une foule de petites tâches "urgentes et obligatoires" qui n'ont pas été intégrées dans le backlog de produit parce qu'elles sont transversales ou correspondent à des bugs détectés au fil de l'eau. Faciles à remarquer, ces user stories arrivent en rafale de post-its© gribouillés durant le scrum.

Mais je m’intéresse particulièrement aux cas où la MOA est en mode Cycle en V tandis que la MOE cherche à devenir Agile. Là, c'est le pompon ! Je signale d’ailleurs que cette technique porte un nom : c'est La RACHE. C’est tout sauf planifié et transparent.
Au-dessus, on a des formalistes, qui pondent des rapports comme ils respirent et ne comprennent pas pourquoi les délais et la qualité (au choix) ne sont pas au rendez-vous en sortie de cycle. Tandis qu'en-dessous, des soutiers codent dans tous les sens, copient-collent outrageusement et prient en secret pour changer de département avant la mise en production... Imaginez Josef Mengele qui ferait de la chirurgie esthétique ; et figurez-vous que ça fonctionne (parfois, et compte tenu du turnover dans les prestataires - Oups) !

Comment en arrive-t-on là ? Mon impression personnelle est que le reporting a quelque chose de rassurant pour les managers et que par ailleurs pas mal de développeurs croient voir dans les méthodes Agiles une occasion de retirer leurs chaînes.
Je pense que la première chose à faire pour bâtir une équipe Agile est d'insister sur l'implication personnelle de CHACUN des acteurs ; d'amener tous les membres de l'équipe (PO, SM, Developer) à se demander en permanence où il en est (dans son rôle, au sein de l'équipe) et où il souhaite aller (que faire pour atteindre l'objectif et améliorer l'ensemble). A condition bien sûr de se donner les moyens de FAVORISER cette implication...
Les uns doivent comprendre que le développement est une activité intellectuelle qui requiert des temps d’isolement, tandis que les autres doivent intégrer que les besoins ne sauraient être figés.

Il est très difficile de sortir de ces situations. Probablement plus difficile que d'accompagner le changement d'un point "V" installé dans les mœurs à un point "A" souhaitable. Il faut réunir tout ce beau monde, déconstruire la situation et parvenir à démontrer son improductivité (à la situation) voire sa nocivité. Chacun vous dira que tout fonctionne mal, mais que de toute façon on ne peut pas changer "ça". Il faut pourtant parvenir à changer chaque bastion en force de proposition, quand il devient manifeste (attention : jeu de mots) que pour chaque nouvelle fonctionnalité, les délais et les charges enfleront constamment. Parce que, tout simplement, les couches de sédiments se sont accumulées malgré les superbes spécifications et rapports de fin de projet. La première victime de ces dysfonctionnements, c’est la qualité.

Non, non, décidément c'est trop compliqué, trop cher. On n'y arrivera pas. Ce n'est pas un VRAI problème... et en effet c’est bien connu : Quand il n’y a pas de solution, c’est qu’il n’y a pas de problème (proverbe Shadock) !
Petit à petit, plutôt que de laisser l’équipe s’améliorer elle-même, on a sauté quelques scrums, rallongé un sprint, et puis on s’est dit que « la démo » pouvait attendre la prochaine fois… En déplacement, le PO a envoyé ses « spécs » en pièce jointe d’un mail à tous… Et on est revenu à un processus désincarné, privé d’échanges (de feedback), sans se l’avouer. Or dans un tel système chacun roule pour soi, c’est comme ça.

Conclusions personnelles

Premièrement : Ce n'est pas parce que les solutions ne sont pas évidentes qu'il faut s'interdire de faire les bons diagnostics. Et chacun devrait s'attacher à les discuter, à les rabâcher sur tous les tons. Il faut à tout prix éviter de ne pas choisir une méthode explicite.
Deuxièmement : Le changement est la plus difficile, voire la plus ingrate, des tâches. Cela peut prendre du temps, échouer, provoquer des antagonismes. Mais il est à la fois l'essence et l'objectif des groupes humains et donc des entreprises vivantes.
Troisièmement : Bien sûr les clients, les utilisateurs, sont demandeurs d'une meilleure qualité, d'une meilleure écoute. Le cycle court itératif apporte lui-même la démonstration de son efficacité dans sa capacité à l'amélioration et à la transparence.

Vous vous êtes déjà retrouvé au milieu du gué (peut-être y êtes-vous en ce moment même), privé de la vision du projet ou de votre capacité à influer dessus ? J'espère que ces quelques arguments vous aideront et vous donneront de l'énergie pour braver les sinistroses rencontrées. L'Agilité, c'est quand chaque voix peut se faire entendre.