Les 20 ans d’Agile : la rébellion ratée
(simplethread.com)<p>- Vingt ans après la publication de l’Agile Manifesto (manifeste Agile), deux faits sautent clairement aux yeux :<br />
1. Le terme Agile a gagné. Personne ne veut être qualifié de non-Agile.<br />
2. En pratique, l’exécution d’Agile est très loin des idées révolutionnaires de ses fondateurs.<br />
- « Tout le monde dit faire de l’Agile, mais il y a très peu de gens réellement agiles. » Comment en est-on arrivé là ?<br />
<br />
[ Whence The Manifesto : comment le manifeste est-il né ]<br />
- En février 2001, un groupe de 17 experts du logiciel s’est réuni dans une station de ski dans l’Utah.<br />
- Après plusieurs jours de discussion, ils ont rédigé ensemble le "Agile Software Development Manifesto".<br />
<br />
- Le point important, c’est qu’ils étaient des "Practitioners" (praticiens). Ce n’étaient ni des PM, ni des CTO, ni des VP Eng. C’étaient des développeurs, des programmeurs, des scientifiques, des ingénieurs. Ils continuaient à écrire du code et à collaborer avec les parties prenantes pour résoudre des problèmes. C’est vraiment essentiel.<br />
- Autre point : l’Agile Manifesto n’est pas né de nulle part. Beaucoup d’entre eux avaient déjà leur propre méthodologie, ou étaient en train de la diffuser.<br />
→ XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, Progmatic Programming<br />
<br />
- Toutes les personnes du groupe avaient une grande expérience du développement logiciel, et cherchaient une alternative aux processus de développement lourds, pilotés par la documentation, qui dominaient alors le marché.<br />
- Le cœur du manifeste repose sur quatre valeurs.<br />
<br />
"En développant des logiciels et en aidant d’autres à en développer, nous avons découvert de meilleures façons de faire. Grâce à ce travail, nous en sommes venus à valoriser :<br />
- les individus et leurs interactions plutôt que les processus et les outils (processes and tools)<br />
- un logiciel opérationnel plutôt qu’une documentation exhaustive (comprehensive documentation)<br />
- la collaboration avec le client plutôt que la négociation contractuelle (contract negotiation)<br />
- l’adaptation au changement plutôt que le suivi d’un plan (following a plan)<br />
Autrement dit, même s’il y a de la valeur dans les éléments de gauche, nous accordons davantage de valeur à ceux de droite."<br />
<br />
[ A New Hope : un nouvel espoir ]<br />
- Vu depuis 2021, il est facile de considérer les pratiques modernes de développement logiciel comme allant de soi, mais en 2001 ces idées étaient extrêmement radicales.<br />
- Commencer à développer un logiciel avant d’avoir collecté toutes les exigences et évalué toutes les fonctionnalités ? C’est de la folie !<br />
- Un point important qu’on a tendance à oublier : à ses débuts, Agile était ouvertement et combativement anti-management.<br />
<br />
- Par exemple, Ken Schwaber, cofondateur de Scrum, défendait l’idée de supprimer tous les chefs de projet, non seulement dans les projets, mais aussi comme métier à l’échelle de l’industrie.<br />
<br />
"Nous avons constaté que le rôle du chef de projet, dans un travail complexe et créatif, est contre-productif.<br />
La pensée du chef de projet, telle qu’elle se matérialise dans le plan de projet,<br />
au lieu de rassembler l’intelligence de chacun pour résoudre au mieux le problème,<br />
limite la créativité et l’intelligence de tous à ce qui est écrit dans le plan."<br />
<br />
- Les scrum masters n’avaient quasiment aucun pouvoir et ne disposaient même pas d’un droit de vote sur les sujets. C’étaient des servant leaders* : ils protégeaient l’équipe et éliminaient les obstacles, mais ne la géraient pas.<br />
→ servant leader : un leader qui se met au service de ses collaborateurs, soutient leur croissance et leur développement, construit une relation de confiance entre leader et équipe, et leur permet de contribuer d’eux-mêmes aux objectifs de l’organisation<br />
- XP avait à l’origine aussi les rôles de Tracker et de Coach, avec un fonctionnement similaire.<br />
<br />
- Alistair Cockburn, créateur de Crystal et de l’architecture hexagonale, a récemment tenu les propos suivants dans un thread sur Twitter :<br />
"Scrum a conclu un marché extraordinaire en territoire hostile :<br />
- les dirigeants pouvaient changer d’orientation comme ils le voulaient 12 fois par an, après chaque sprint<br />
- l’équipe obtenait un mois de calme absolu, sans interruption ni changement de direction, pour mener le travail de réflexion et d’exécution lourd<br />
- l’équipe pouvait annoncer, lors du Bid (pour établir les priorités), ce qu’elle pouvait ou non accomplir en un mois, sans ingérence du management<br />
- aucun dirigeant n’a jamais eu un meilleur accord<br />
- aucune équipe de développement n’a jamais eu un meilleur accord<br />
"<br />
<br />
- Après plus de 15 ans passés dans des équipes Agile, en tant que scrum master certifié, et après avoir lu de nombreux livres populaires sur le sujet, je n’avais jamais vu l’idée de Scrum expliquée de manière aussi claire et concise.<br />
- Scrum a été conçu pour fonctionner dans un environnement hostile. C’est un contrat entre des développeurs qui ont besoin de temps pour réfléchir et explorer, et des managers coercitifs.<br />
<br />
[ The Empire Strikes Back : l’Empire contre-attaque ]<br />
- D’une certaine manière, Agile était un mouvement ouvrier de terrain. Il est parti des praticiens pour remonter jusqu’aux dirigeants. Comment cela a-t-il pu réussir ?<br />
- En partie parce que le nombre de développeurs augmentait, ainsi que la valeur qu’ils apportaient au business.<br />
- Mais surtout parce que la méthode traditionnelle en cascade ne fonctionnait pas correctement.<br />
- À mesure que le logiciel devenait plus complexe, que le business allait plus vite et que les utilisateurs devenaient plus exigeants, il est devenu impossible de tout planifier à l’avance.<br />
- Adopter un développement itératif était logique, mais c’était aussi un peu effrayant pour les managers habitués à tout planifier.<br />
<br />
- Au milieu des années 2000, les dirigeants n’étaient toujours pas convaincus.<br />
- Puis quelqu’un a fini par dire : "Essayons donc cette idée folle dont les ingénieurs parlent sans arrêt. De toute façon, on ne tiendra pas nos délais actuels, alors qu’est-ce qui pourrait être pire ?"<br />
- Et de façon surprenante, ça a commencé à marcher. Les équipes étaient d’abord un peu crispées (et lentes), puis elles ont progressivement compris quels schémas fonctionnaient pour chacune, et ont commencé à accélérer.<br />
- Après quelques sprints, elles ont découvert la puissance d’un logiciel opérationnel, de la collaboration, du temps consacré à l’inspection et à l’adaptation, et du fait de placer tout cela au-dessus du reste.<br />
<br />
- En l’espace d’environ cinq ans, Agile est passé d’une méthodologie dont on avait entendu parler à quelque chose qui n’était plus inconnu de tout le monde.<br />
- En 2005, Agile et le TDD constituaient un véritable facteur de différenciation.<br />
- En 2010, les équipes logicielles modernes pratiquaient toutes une forme d’Agile.<br />
- Du moins dans le conseil, c’était la bulle. Les grandes entreprises ont toujours avancé plus lentement, bien sûr.<br />
<br />
"On l’a fait ! On a gagné ! Félicitons-nous tous !"<br />
Fin de l’histoire, vous pouvez fermer l’onglet du navigateur.<br />
<br />
"Winning was easy, young man. Governing’s harder."<br />
"Gagner, c’était facile, jeune homme. Gouverner, c’est plus difficile."<br />
→ George Washington tel qu’il est représenté dans la comédie musicale Hamilton<br />
<br />
- Malheureusement, comme pour beaucoup de révolutions, l’histoire d’Agile ne s’est pas déroulée comme ses fondateurs l’avaient imaginée.<br />
→ il s’est avéré que mettre en avant les "individus et les interactions" est une idée difficile à faire passer. Il est bien plus facile de vendre des processus et des outils.<br />
→ il s’est avéré qu’un "logiciel opérationnel" est plus difficile à produire que des plans irréalistes et beaucoup de documentation.<br />
→ la "collaboration avec le client" exige de la confiance et de la vulnérabilité (vulnerability), deux choses qui ne sont pas toujours présentes dans le monde de l’entreprise.<br />
→ quant à "l’adaptation au changement", le poids penche souvent davantage vers des dirigeants qui doivent établir des plans à long terme et garder le contrôle.<br />
<br />
"Il s’est avéré que, lorsqu’Agile est mal mis en œuvre, cela ressemble souvent au chaos."<br />
<br />
- Mais cela ne signifie pas que ces quatre valeurs sont mauvaises.<br />
- Cela signifie que pour que tout cela fonctionne correctement, il faut un certain effort, ainsi que le courage d’accepter que le logiciel est par nature désordonné et chaotique.<br />
- Il faut comprendre et croire que si l’on continue à apprendre, à s’adapter, à s’améliorer et à livrer, on peut finir dans un endroit bien meilleur que la cascade : un endroit bien plus honnête, réaliste et productif.<br />
<br />
"Le mouvement Agile n’est pas anti-méthodologie.<br />
En réalité, beaucoup d’entre nous souhaitent que le mot "méthodologie" retrouve sa crédibilité. Nous voulons que l’équilibre soit rétabli.<br />
Nous acceptons la modélisation, mais pas pour entasser des diagrammes dans un entrepôt poussiéreux de l’entreprise.<br />
Nous acceptons la documentation, mais pas des livres de centaines de pages qui ne sont jamais maintenus et presque jamais utilisés.<br />
Nous faisons des plans, mais nous reconnaissons leurs limites dans un environnement turbulent.<br />
Ceux qui qualifient de "hackers" les partisans de XP, Scrum ou d’autres méthodologies agiles ignorent la définition originelle des termes "méthodologie" et "hacker"."<br />
- Jim Highsmith, History: The Agile Manifesto<br />
<br />
- Voilà les points importants. Nous continuons à faire des plans et à produire de la documentation, et nous devons rester rigoureux avec Agile. Il s’agit d’équilibre.<br />
- Mais si votre organisation a du mal avec sa transformation Agile et sombre dans le chaos, alors au moment où quelqu’un vous tend un canot de sauvetage sous la forme d’une certification, d’un processus ou d’un outil, vous sautez dedans.<br />
- Les dirigeants comprennent bien mieux les processus et les outils que les "équipes auto-organisées".<br />
<br />
[ R̶e̶t̶u̶r̶n̶ ̶o̶f̶ ̶t̶h̶e̶ Rogue One : Rogue One ne revient pas ]<br />
- C’est là que ma structure en trois actes s’effondre un peu, parce qu’on ne voit pas apparaître de courageux rebelles revenus sans l’étiquette Agile.<br />
<br />
- Les éditeurs d’outils, les consultants en processus et les experts font souvent des promesses qu’ils ne pourront jamais tenir.<br />
- C’est pour cela qu’on a créé SAFe (Scale Agile Framework for Enterprise), le Scaled Scrum et d’autres versions d’Agile pour les grandes entreprises.<br />
- Ces frameworks n’ont pas été conçus avec une intention malveillante, et ils ont probablement une certaine valeur dans le bon contexte.<br />
- Mais je ne les appellerais pas Agile.<br />
- Dès qu’on essaie de faire passer à l’échelle une méthodologie centrée sur les individus et les interactions, on rencontre inévitablement des problèmes, et les valeurs d’origine de la méthodologie sont dégradées.<br />
<br />
- Texte célèbre écrit en 2018 par Ron Jeffries, signataire du manifeste Agile et cofondateur de XP :<br />
<br />
"Les développeurs doivent abandonner Agile.<br />
Quand les idées dites 'Agile' sont mal appliquées, elles conduisent à plus d’interférences avec les développeurs, moins de temps pour travailler, plus de pression, et à l’exigence d’"aller plus vite". Ce n’est pas bon pour les développeurs, et au final ce n’est pas bon non plus pour l’entreprise. En effet, quand on ne pratique pas 'Agile' correctement, on obtient souvent bien plus de défauts et des avancées plus lentes que ce qu’il est réellement possible d’atteindre. Souvent, les très bons développeurs quittent alors l’entreprise, ce qui aboutit à des organisations moins efficaces qu’avant l’adoption d’"Agile"."<br />
<br />
- Autre texte célèbre, écrit en 2014 par Dave Thomas, autre signataire du manifeste et cofondateur de The Pragmatic Programming :<br />
<br />
"Agile est mort. (Vive l’agilité.)<br />
Le mot 'Agile' a été détourné (subvert) jusqu’à devenir pratiquement vide de sens, et la communauté Agile est globalement devenue un endroit où consultants et éditeurs vendent leurs services et leurs produits. À mesure que le manifeste gagnait en popularité, le mot Agile est devenu un aimant attirant tout ce qui avait besoin d’un soutien, d’heures à facturer ou de produits à vendre ; il est ainsi devenu un terme marketing.<br />
<br />
Je pense donc qu’il est temps de retirer le mot 'Agile'."<br />
<br />
[ Retro : retour en arrière ]<br />
- Ce qui est vraiment triste, c’est de voir de jeunes développeurs considérer Agile comme un moyen de les dénigrer, de pousser les dirigeants à imposer des promesses irréalistes, et d’inciter les développeurs à travailler énormément d’heures.<br />
- Le seul Agile qu’ils connaissent est un mécanisme de contrôle qui leur a été imposé, et non un outil d’émancipation qu’on accueillait avec enthousiasme.<br />
- J’espère néanmoins qu’ouvrir une discussion sur l’histoire et sur la vision d’origine nous aidera à nous souvenir de la direction à prendre à l’avenir.<br />
<br />
- Malgré tout, la bonne nouvelle, c’est que les principes de l’Agile Manifesto restent aussi sages et pertinents aujourd’hui qu’il y a 20 ans. Et même des figures supposées apostates comme Jeffries ou Thomas semblent toujours le penser.<br />
<br />
- Dans le texte mentionné plus haut, Jeffries dit ceci :<br />
"Cependant, les valeurs et principes du Manifesto for Agile Software Development continuent de fournir, à mes yeux, la meilleure manière de construire des logiciels ; et, à partir de mon expérience longue et variée, je suivrai ces valeurs et ces principes dans les grandes organisations, quelle que soit la méthodologie utilisée."<br />
<br />
- Je suis d’accord avec cet avis.<br />
- Aujourd’hui, parler d’Agile n’a plus rien de branché ni de cool. Agile, c’est devenu ennuyeux.<br />
"Tout le monde fait de l’Agile, non ?"<br />
- C’est justement le moment idéal pour revenir sur les 20 dernières années et se poser quelques questions :<br />
→ Qu’est-ce qui a bien fonctionné ?<br />
→ Qu’est-ce qui a mal tourné ?<br />
→ Que voudrions-nous faire différemment la prochaine fois ?<br />
- Dans les prochains mois, j’ai l’intention de revenir sur les 12 principes originels de l’Agile, d’en recontextualiser le sens initial, et d’en examiner la valeur dans l’environnement actuel du développement logiciel.<br />
<br />
"J’espère qu’en étudiant les principes fondateurs, nous pourrons apprendre du passé et, pour reprendre les mots de Dave Thomas, même si nous abandonnons 'Agile', conserver 'Agility' (l’agilité)."</p>
3 commentaires