En seulement 68 mots, le Manifeste Agile, a modifié de façon pérenne notre manière de gérer les projets. Au cours de ces dernières années, ces mots ainsi que les principes et méthodes qui en ont découlés, ont été adoptés par d’innombrables personnes. L’Agile s’est propagée bien au-delà de ses racines de développement de logiciels et s’est aujourd’hui étendue à tout type de secteurs et de projets. Un Agile omniprésent et pourtant pas immortel. Car si le manifeste Agile était porteur d’idées aussi radicales que visionnaires, ces grandes idées ont été diluées jusqu’à devenir au mieux des arguments marketing et au pire des parodies empêchant la véritable agilité. Il s’agissait de produire des logiciels de qualité de manière plus intelligente et adaptable ; en guise de cela nous avons obtenu des gourous menant des ateliers Lego à 1000€ l’heure et réinventant la promenade en « co-walking ». Ainsi, peut-être est-il temps désormais de se rendre à l’évidence de faire objectivement la part des choses.
Février 2001 : Google est encore un illustre inconnu, Netflix est à la pointe de l’innovation grâce à ses locations de DVD, les téléphones portables ressemblent à des briques, on danse sur les Backstreet Boys et votre stagiaire n’était probablement pas encore né. Au même moment, ceux qui seront plus tard appelés les Snowbird 17 se réunissent dans les montagnes enneigées de l’Utah pour discuter de l’avenir du développement : l’Agile est né. Depuis, le manifeste Agile est resté le même, comme en témoigne le site vieillot et poussiéreux sur lequel il est hébergé. Inutile de faire la liste des grands changements historiques et technologiques qui ont eu lieu depuis (une pandémie mondiale est même survenue) ; force est de constater que le monde dans lequel l’Agile évolue n’est plus le même qu’il y a 20 ans. Et bien que ces dernières décennies aient démontré que rien ne dure, particulièrement en termes de technologie, l’Agile semble immunisé contre les ravages du temps. Depuis la naissance de l’Agile l’Iphone a été remis au goût du jour 29 fois, n’est-il pas temps de donner un lifting à l’Agile ?
Outre son âge certain, l’Agile n’est pas une panacée omnipotente s’adaptant parfaitement à toutes les situations. Selon les projets, le travail peut être effectué de manière plus efficace en utilisant les méthodes Lean ou encore Waterfall (je vois déjà certains relever leurs sourcils d’effroi à cette idée). Des projets différents nécessitent des stratégies, des équipes, des cycles de vie et des méthodes différentes. Plus encore, l’Agile est difficilement scalable. Les méthodes Agiles reposent fortement sur la communication, de la sorte, une équipe nombreuse rend difficile l’application des méthodes Agiles. Scaled Agile Framework (ou SAFe) a pour ambition de répondre à ce défi. Toutefois les détracteurs de cette méthode sont nombreux. « SAFe impose des processus et une structure qui étouffent la véritable agilité. » explique Sean Dexter[1], Senior User Expérience/Product Designer chez Cigna « le top management propose des idées et les opérationnels les exécutent. On ignore la possibilité que les personnes les plus proches du travail soient les mieux équipées pour prendre des décisions à ce sujet. ». Derrière le manque de scalabilité de l’Agile, se trouvent aussi de nombreuses habitudes et cérémonies contre-productives. Les sprints tout d’abord. Bien trop souvent on voit des équipes aligner 26 sprints de 2 semaines consécutifs au long d’une année : non seulement le mot est mal adapté (on devrait plutôt parler de marathon), mais surtout un tel rythme n’est pas humain puisque non soutenable dans la durée, ce qui est incompatible avec l’un des 12 principes du manifeste agile. Les Story Points et Planning Poker ont eux aussi des bénéfices limités. Si l’idée d’avoir des tâches que l’on peut clairement mesurer est particulièrement plaisante, dans bien des cas ces mesures sont faites sans abaques, au doigt mouillé, et sont donc dénuées de sens puisqu’elles ne donnent finalement que peu de visibilité. Enfin, les Daily Meetings se heurtent eux aussi à la réalité de la pratique. Ces réunions qui doivent en théorie être un moment d’échange et synchronisation, se transforment très régulièrement en performances où chacun essaye plutôt de rappeler son utilité. « C’est essayer de démontrer à l’équipe que oui, j’ai effectivement travaillé hier. J’ai été un membre utile. S’il vous plaît, ne me virez pas. » explique Chris Toomey, co-host de The Bike Shed[2].
Un autre point qui est discutable : le lancement rapide d’un logiciel est-il vraiment la priorité absolue ? Dans leur article Have we taken Agile too Far (Harvard Business Review)[1], Colin Bryar et Bill Carr expliquent que le problème fondamental de l’Agile est le rythme intense dans lequel la méthode place les développeurs et l’équipe. Cette dernière doit produire un MVP en quelques semaines et se concentre sur ce sujet plutôt que sur le potentiel du produit et l’étendue de ce qu’il devrait accomplir. L’équipe réduit ainsi ses ambitions. Au lieu d’une percée majeure, elle tend à n’apporter que des améliorations incrémentales aux offres existantes. Et si les développeurs font preuve d’audace, leur produit minimum viable n’est pas vraiment viable et les retours clients ne sont pas vraiment exploitables. « L’équipe peut se dire que toutes les informations qu’elle obtient sont précieuses pour un futur produit révolutionnaire. Mais cet avenir vient rarement. Trop souvent, le processus de sprints de deux semaines devient l’habitude, et l’équipe n’a jamais le temps et l’espace pour prendre du recul et réfléchir à ce qui est nécessaire pour vraiment impressionner ses clients. » Have we taken Agile too Far (Harvard Business Review), Colin Bryar et Bill Carr
Au-delà de ces problèmes inhérents à l’ADN Agile, il convient surtout de signaler les problèmes dans l’application des méthodes. Une enquête de Deloitte et McKinsey[1] montre que plus de 90 % des cadres supérieurs accordent une haute priorité à l’agilité, alors que moins de 10 % se déclarent très agiles. L’écart entre l’aspiration et la réalité pousse nombre d’entreprises à prétendre être Agile sans l’être réellement. Un phénomène qui déjà son nom : « Dark Agile » ou « Faux Agile ». Martin Fowler, un des signataires du manifeste, explique que si en apparence le monde du développement logiciel est agile, la réalité est plus troublante voir même sombre car une grande partie de ce qui est fait est du « faux agile », soit une mise en œuvre ignorant les valeurs et les principes agiles[2]. Le Dark Agile est protéiforme et n’existe pas que d’une seule manière. Certains vont utiliser le mot magique Agile comme une excuse pour finalement éviter toute planification et préparation. Chez d’autres l’implémentation des méthodes est superficielle et mécanique : des organisations se disent Agile et pourtant continuent de prioriser les processus et outils plutôt que les personnes et interactions. Au lieu de laisser l’équipe choisir ses méthodes, le management impose un processus Agile à taille unique et rigide, ce qui finalement étouffe l’agilité. Le curseur Agile peut aussi être poussé trop bas, avec des méthodes diluées à tel point qu’elles ne peuvent être efficaces, ou encore trop haut avec des organisations qui embrassent les méthodes de manière rigide sans comprendre les principes Agile ou sans l’appliquer intelligemment. Les déclinaisons du Dark Agile sont infinies. Que l’on appelle ça Dark ou Faux Agile, ces subversions conduisent souvent à des situations qui vont à l’encontre des intentions du Manifeste : micro-management, rythme épuisant, burn-out, manque de livraison…
Pourtant malgré tous ces écueils, l’Agile prospère et on voit peu – si ce n’est aucune – remise en question. Pourquoi ? Parce que l’Agile a été élevée au rang de divinité. L’Agile (orthographié avec un A majuscule déifique), a tout de la religion, si ce n’est du culte sectaire. Un sujet étudié par Arnaud Dubergier dans La religion Scrum[1] et Darius Blasband dans Agile as full-featured religious dogma[2]. D’abord la terminologie. Comme tout dogme, l’Agile a un jargon qui incarne le culte et dont les fanatiques usent à profusion : Sprints, Scrums, Epics, Kanban, Product Owner, Scrum Master, Daily, Burndown chart, la liste est interminable. Il y a les rites, comme se réunir debout tous les matins, et les objets rituels, comme le tableau Kanban ou le jeu de cartes pour jouer au Planning Poker. Et, à l’instar de nombreuses religions, l’Agile a aussi ses fanatiques, regroupés en sous-cultes toujours plus nuancés, s’accusant mutuellement de ne pas être assez purs et chacun prétendant être plus Agile et authentiques que l’autre. Ce dogmatisme va prodigieusement à l’encontre de la philosophie profonde de l’Agile. On rend l’Agile binaire et manichéen alors que son texte fondateur ne l’est pas : undefined Précisément, même si les éléments à droite ont de la valeur, nous reconnaissons davantage de valeur dans les éléments à gauche. » Le Manifeste Agile[3] De plus, cette pression à se conformer au dogme fait que l’équipe perd petit à petit sa capacité à penser en dehors des sentiers battus et tend à fuir la diversité. Ce qui, encore une fois, empêche l’agilité. Mais ce qui est encore plus affligeant et contre-productif est le respect religieux qu’inspire le mot Agile. Comme le remarque Darius Blasband[4], l’Agile est devenu une parole d’évangile infaillible. Si un projet Agile échoue, c’est toujours parce que la méthode n’a pas été correctement ou pas assez appliquée. L’Agile en tant que tel ne peut être remis en cause épistémologiquement, puisqu’il fonctionne parfaitement pour ses croyants. Ceux qui échouent sont des infidèles qui n’ont personne d’autre à blâmer qu’eux-mêmes. L’Agile ne répond donc pas au niveau le plus trivial du test de réfutabilité de Karl Popper. En effet, « le critère de la scientificité d’une théorie réside dans la possibilité de l’invalider, de la réfuter ou encore de la tester »[1]. Or, si sa mise en œuvre peut être remise en cause, l’Agile n’est jamais considéré comme étant en faux lui-même. Ce n’est ni de la science ni de la technologie. C’est un dogme. undefinedundefinedundefined Comme partout où le fanatisme réside, les opportunités financières sont pléthores. Car si l’Agile n’est pas réellement un facteur de succès infaillible, il est en revanche synonyme d’argent facile. Dave Thomas, un des signataires du manifeste Agile, lancé la charge dans son article Agile is Dead (Long Live Agility)[1]. L’un des principaux problèmes pour lui est que “Agile” était à l’origine censé être un adjectif, mais a été dénaturé en un nom. Au-delà du problème de grammaire, c’est l’autoroute au détournement commercial qu’offre le mot Agile qui est dangereux. Depuis que le manifeste est devenu populaire, « Agile » est devenu un mot magique augmentant la valeur marchande de n’importe quel obscur service, outil ou formation. Dave Thomas parle ainsi de ceux qui « prennent l’âme de nos idées afin de nous les revendre ». L’Agile est vendu comme une solution miracle donnant le pouvoir aux équipes, leur permettant d’atteindre une rapidité extrême et une croissance sans limite. Rapidité, croissance, pouvoir, efficacité : le vocabulaire du vendeur de potions miracles. undefinedundefined D’autres signataires du manifeste déplorent aussi que le mot Agile soit devenu un prétexte marketing vide de sens. Martin Fowler appelle ça « l’Agile Industrial Complex » et explique que c’est un des principaux fléaux à combattre aujourd’hui. Alistair Cockburn remarque quant à lui que « de nombreuses personnes transforment les méthodes agiles en argent facile. L’agile est maintenant une source de profits facile. Les certifications de deux jours sont le fléau de l’industrie informatique ; et les transformations organisationnelles agiles, la poule aux œufs d’or[3]
Ainsi, comme en fin de sprint il est temps de faire la rétro. De voir ce qui marche et ce qui ne marche pas. L’Agile n’est pas magique. Il n’est pas synonyme de réussite systématique ou de panacée. Si nous creusons un peu, nous pouvons constater que la plupart des projets agiles réussis sont à l’origine des projets portés par une vision claire et une équipe forte. Ainsi, plutôt que de considérer l’Agile comme parfait, il serait plutôt temps de privilégier le pragmatisme au dogmatisme, et de mettre en avant la finalité plutôt que les moyens. Outre certaines pratiques Agiles qui sont peu efficaces, voire qui empêchent l’agilité, l’Agile symbolise aujourd’hui un danger à la bonne gestion de projet. Dans bon nombre de cas les équipes qui se déclarent Agile font en réalité du Dark Agile, et pour celles qui pratiquent bien les méthodes agiles, on retrouve trop souvent un dogmatisme alarmant empêchant toute agilité et remise en question. Pire encore, alors que seulement une portion congrue des projets qui se disent agiles le sont vraiment, le mot s’est mué en un prétexte marketing ne servant qu’à des fins pécuniaires. Ainsi, 20 ans après la création du manifeste, alors que nous vivons dans un monde versatile où l’amélioration continue est toujours plus nécessaire il est temps de se rendre à l’évidence : l’Agile, tel qu’on le pratique aujourd’hui, est dépassé.