Les errements de l’agilité

25 ans après le Développement rapide d’application, 17 ans après XP, et 10 ans après PUMA, les « Agilistes » face à leurs échecs redécouvrent les valeurs sur lesquelles les « scrumistes » avaient craché et s’enfoncent dans le passé pour tenter de s’en sortir et proposer une nouvelle offre « à faire rêver le client ».

Franchement,  je suis exaspéré par le constat  de l’évolution, ou plutôt du manque d’évolution, des méthodes itératives qualifiées maintenant d’Agiles.  Et je ne suis pas le seul !

Il faut se souvenir que cette aventure avait commencé en 1991 avec  la publication de la méthode  RAD. Contrairement  à ce qui fut prétendu  plus tard par certaines sociétés de services impliquées  dans la vente de Scrum, la version française  de cette méthode couvrait avec complétude les différents aspects de la conduite du projet, de la qualité du code, des aspects financiers et de la problématique des risques (vérifiable sur RAD.fr ou sur Wikipédia).  Malheureusement James Martin, son auteur prolifique, passa rapidement à autre chose (The Meaning of the 21st Century).

En 1999, huit années plus tard, l’eXtrem Programming de Kent Beck portait en avant les techniques de production du code.  Il fallut ensuite attendre l’Agile Manifesto de 2001 pour décider  Ken Schwaber et Mike Beedle à publier sur Scrum, une méthode sommaire de contrôle incrémental du livrable. Elle n’était d’ailleurs pas vraiment itérative, car elle n'autorisait pas les changements en cours de développement (Sprint).  Jeff Sutherland en fut ensuite un promoteur diligent, mais rien de plus.

Les autres méthodes – une douzaine, toutes américaines – ne sentirent pas venir danger. Refusant de fusionner, elles disparurent  naturellement devant le rouleau compresseur marketing de Scrum.

Depuis, aucune évolution fondamentale !  Scrum se limite toujours au pilotage incrémental du projet et  néglige totalement l’expression des exigences,  la gestion des risques, les aspects financiers, la qualité technique et tout ce qui représente le quotidien des chefs de projets (d’ailleurs, Scrum supprime théoriquement cette fonction se coupant par là même de la réalité de la plupart  entreprises).

Certains « agilistes » se rendirent  compte du problème et tentèrent de réinventer la roue carrée en s’appuyant sur les techniques oubliées.  Ce fut le temps du « back to the futur »  avec le « Lean », une approche post-industrielle de la « qualité économique ». Elle avait déjà tenté de s’étendre dans les années 80 au monde des bureaux (Lean office, Qualité Totale).  Maintenant  elle apparaissait comme la dernière solution miracle pour faciliter la production applicative (Lean Développement).  Certains tentèrent leur chance  avec le « Kaban »  une technique de gestion de production déployée à la fin des années 1950.  Mais ce n’était qu’un outil visuel, devenu par contre indispensable à l’affichage mural des méthodes Agiles.

Apparu alors le Software craftsmanship  (artisanat ou professionnalisme du logiciel), une approche de développement d’applications née aux USA en 2008. D'après le Software craftsmanship,  il ne suffit pas qu'un logiciel soit fonctionnel, il doit aussi être bien conçu et économique. Le Software craftsmanship met alors l'accent sur les compétences de conception et de codage des développeurs (comme l’eXtrem Programming), mais en y prenant en compte des préoccupations le plus souvent économiques et financières (comme le faisait la méthode RAD).  En intégrant ces responsabilités auxquelles ne peuvent plus échapper les projets actuels, ce mouvement se voulait devenir une réponse économique à l’externalisation systématique du codage.

C’était mieux que rien, mais aucune des approches ne réglait techniquement  la gestion du coût des changements avec une métrique digne de ce nom.  L’ensemble de ces problématique est d’ailleurs la raison pour laquelle j’ai conçu en 2008 PUMA (Processus Urbanisant les Méthodes Agiles) comme un  framework  global de développement proposant des réponses  techniques « agilisées »  dans le respect des méthodes déjà connues de Scrum et d’XP.

Les autres errements de l’agilité furent encore plus déroutants. D’année en année, au lieu de se concentrer  sur l’essentiel, les consultants  se mirent à privilégier  à l’extrême les « serious  game », puis les approches  relationnelles comme la sociocratie  et ensuite l’holacratie (utile pour gérer  une réunion, mais  effet de meute dans les prises de décision ). Il  y a deux ans, les conférences accueillaient pléthore  d’avocats.  Les échecs des développements Scrum devenaient flagrants.  La profession  se retrouvait  loin du rêve de partenariat et du client « membre de l’équipe ».

Revenons à Scrum. Récemment,  j’ai eu l’occasion de vérifier son implantation concrète  dans plusieurs  entreprises.  La déclaration initiale était : « Nous sommes  Scrum et Agile ». Au bout de quelques questions, la réalité apparaissait : pas de mode plateau, pas de mode projet, pas d’autonomie de l’équipe,  présence maintenue de chefs du projet tenant généralement le rôle de scrum master. À ma question « en quoi êtes-vous agile ? » la réponse était  généralement : « Nous tenons des réunions tous les matins et utilisons des post-it   ». Franchement,  après cela comment peut-on encore s’étonner d’absence de résultat.

Devant  ces errements et ces bricolages, on comprendra que  l’agilité ne fasse pas l’unanimité. Lors de ses conférences en Finlande, le grand développeur Erik Meijer attaque particulièrement l’agilité contemporaine et la méthode Scrum: « Agile est un cancer que nous devons éliminer de l’industrie ». Dave Thomas, l’un des 17 signataires du Manifeste agile s’insurge également de l’usage actuel du terme Agile : « Le mot – Agile - a été détourné au point ou il est devenu vide de sens. Et ce qui passe pour une communauté agile est devenu une arène pour les consultants et les entreprises qui veulent vendre leurs produits et services ».

Conclusion : Pathétique ! : Vingt-cinq ans après le Développement rapide d’application, dix-sept après XP, et dix ans après PUMA, les « Agilistes » face à leurs échecs  redécouvrent les valeurs sur lesquelles les « scrumistes »  avaient craché et s’enfoncent dans le passé pour tenter de s’en sortir et proposer une nouvelle offre « à faire rêver le client ».

Office / Vendre