Agile est la Rigor Mortis comme religion d’État du logiciel

Il n’est pas rare dans le monde de l’ingénierie logicielle d’entendre des proclamations de la mort d’Agile de la part de personnes ayant un intérêt direct dans la méthodologie, affirmant qu’à moins que nous ne fassions preuve d’une plus grande foi, elle sera perdue, et dans les cas où elle échoue, elle n’a tout simplement pas été mise en œuvre correctement – rappelant d’autres affirmations suivant le sophisme du « pas de vrai Écossais » comme « le vrai communisme n’a jamais été essayé ».

Malgré sa présence dans des catastrophes logicielles allant des erreurs judiciaires aux désastres de logiciels aéronautiques, la réalité est qu'Agile a occupé une position qui s'apparente en quelque sorte à une religion professionnelle de l'ingénierie logicielle.

Cette situation a profondément changé au cours des derniers mois. Depuis que j'ai travaillé sur une étude il y a 6 mois montrant que les projets logiciels Agile avaient un taux d'échec supérieur de 268 % , une pléthore de recherches ont été publiées corroborant ce travail.

Comme le communisme ou la guérison par la foi, les fantasmes de grandeur selon lesquels des solutions universellement bonnes, mais irréalistes, peuvent résoudre tous nos problèmes séduiront toujours certains, malgré les preuves - mais ce qui a fondamentalement changé maintenant, c'est qu'il existe un consentement éclairé quant à savoir s'il faut suivre Agile ou faire quelque chose de différent.

(Il ne fait aucun doute que les nouvelles internationales associées à la mise à jour bâclée du logiciel CrowdStrike ont certainement contribué à faire passer le message que j'essayais de faire valoir.)

Malgré les efforts répugnants déployés par certains membres de la communauté Agile pour m'empêcher de parler d'Agile, il est important d'être magnanime dans la victoire, je ne chercherai donc pas à relancer les arguments ici - au lieu de cela, je pense qu'il vaut la peine de discuter des développements récents et de la route à suivre, 6 mois plus tard.

La recherche DORA de Google s'appuie sur Agile

JL Partners, à qui j’ai confié la réalisation de l’étude sur le taux d’échec Agile, a connu des mois exceptionnels. Contrairement à de nombreux autres cabinets qui effectuent des recherches avec une responsabilité limitée, ils testent régulièrement leurs modèles en prédisant les élections. En ce qui concerne les élections britanniques, ils ont produit des prévisions parmi les plus précises . Les choses sont encore plus remarquables en ce qui concerne les élections américaines, comme le rapporte Politico :

… JL Partners pourrait bien être l’un des plus précis dans ses prévisions finales pré-électorales. Le modèle final de la société n’était que l’un des deux à prévoir une victoire de Trump et il prévoyait également qu’il remporterait le Collège électoral avec 287-251, soit la marge de victoire la plus élevée de tous les sondeurs. Il était également l’un des rares sondeurs à prédire que Trump remporterait le vote populaire.

De plus, une étude de la RAND Corporation, initialement menée pour le ministère de la Défense américain, a révélé que le développement de l'IA et l'agilité ne font pas bon ménage . De plus, Synodus (un fournisseur mondial de technologies qui fournit des entreprises du Fortune 500 comme BOC Aviation, KPMG et Unilever) rapporte qu'en s'éloignant d'Agile , il constate qu'il livre ses projets 2 à 3 fois plus vite et qu'une compagnie aérienne de premier plan a économisé 63 % de ses coûts de développement.

Ceci en dépit du fait que la vitesse et le coût sont des mesures traditionnellement associées à Agile et LEAN, tandis que l’approche Impact Engineering se concentre sur l’impact comme mesure principale.

Enfin, comme l’a écrit Colm Campbell dans l’article « P-Hacking with Dinosaurs », les affirmations avancées par la « mafia agile » en réponse à l’étude sur le taux d’échec agile ont été complètement réfutées, ne laissant que des attaques personnelles pathétiques.

Cependant, l'un des domaines de recherche les plus surprenants vient peut-être de l'équipe DORA de Google. DORA elle-même trouve ses racines dans le mouvement DevOps, qui est lui-même une créature d'Agile. Leur rapport annuel sur l'état de DevOps pour 2024 n'a pas reçu de couverture particulièrement étendue cette année étant donné le temps consacré à la recherche Agile, mais il est intéressant de voir qu'ils tournent également le dos à Agile.

Maintenant, je dois noter que j'ai critiqué la méthodologie de l'équipe DORA (depuis que j'ai changé d'avis sur Agile, DevOps, etc.) car les principales mesures qu'ils utilisent pour mesurer les choses sont axées sur la vitesse de livraison ( ce qui, nous le savons, n'est pas ce que les utilisateurs veulent ), mais le fait qu'ils voient cela même en utilisant leur approche indique qu'il se passe quelque chose de plus profond ici.

À la page 64 du rapport sur l’état de DevOps 2024, ils affirment :

« Le manifeste Agile prône « des logiciels fonctionnels plutôt qu'une documentation complète ». Nous continuons cependant à constater qu'une documentation de qualité est un élément clé d'un logiciel fonctionnel. »

De plus, à la page 82, ils semblent tourner le dos à DevOps lui-même :

« Nous nous engageons à respecter les principes fondamentaux qui ont toujours fait partie du mouvement DevOps : la culture, la collaboration, l'automatisation, l'apprentissage et l'utilisation de la technologie pour atteindre les objectifs commerciaux. Notre communauté et nos recherches bénéficient des points de vue de divers rôles, y compris de personnes qui ne sont peut-être pas associées à l'étiquette « DevOps ». Vous devez vous attendre à voir le terme « DevOps » disparaître des projecteurs. »

J’ai toujours des problèmes avec leur méthodologie de recherche ; les critères utilisés pour mesurer le succès sont axés sur la vitesse et, de plus, ils continuent de prôner un leadership transformationnel malgré les recherches psychologiques dans ce domaine qui remettent en question ces approches.

Au niveau humain, il semble remarquablement grossier de se concentrer autant sur la tentative de transformer les organisations et les personnes sans leur consentement éclairé, tout en omettant de reconnaître qu’il n’y a souvent pas de meilleure source d’apprentissage que nos propres erreurs (dans la mesure où nous avons le consentement éclairé pour les faire), une critique clé que j’ai à l’égard de travaux comme The Pheonix Project et The Unicorn Project .

Il est néanmoins remarquable de constater une corroboration croissante de l’Impact Engineering par rapport aux mesures traditionnelles Agile et DevOps.

Scrum, TDD et modèles de conception

Lorsque The Register m’a interviewé il y a quelques mois dans l’article « Study backer: Catastrophic takes on Agile overemphasize new features » , je n’ai pas caché les trois facteurs qui me posaient problème dans les approches modernes d’Agile, de DevOps et de transformation numérique :

1. Approches Agile qui déprécient les exigences, malgré des catastrophes telles que le scandale de la Poste et les crashs du Boeing 737 Max 8 .

   
   

2. Les implémentations de DevOps qui privilégient la rapidité de livraison des nouvelles fonctionnalités et la récupération après les problèmes plutôt que la prévention des problèmes en premier lieu - malgré les recherches montrant que le public considère l'obtention des dernières fonctionnalités le plus rapidement possible commela chose la moins importante pour eux lors de l'utilisation de systèmes informatiques, la sécurité des données, l'exactitude des données et l'absence de bugs graves étant les facteurs les plus importants.

   
   

3. Les tentatives de transformation organisationnelle ascendante sans obtenir le consentement éclairé, négligeant l'importance de permettre aux gens d'apprendre de leurs propres erreurs qu'ils ont le consentement éclairé de faire - avec de tels programmes vendus comme des succès infaillibles se terminant dans leur immense majorité par une misère stressante et un échec.

   
   

Lorsque j'ai commencé à faire des recherches sur les catastrophes logicielles et les ordinateurs tueurs (comme l'a rapporté Forbes en avril dernier ), ce sont ces trois facteurs qui ont commencé à me poser de plus en plus de problèmes moraux. Je n'avais aucun problème réel avec les différentes approches de développement de logiciels ou les techniques de gestion de projet, car je ne voyais pas le même lien avec les études de cas de catastrophes que j'étudiais. Je n'éprouvais pas le besoin d'exprimer mon point de vue personnel en tant qu'ingénieur sur ces autres questions.

Néanmoins, il est intéressant de voir que le rayon d'action s'est élargi au-delà de ces trois domaines initiaux vers d'autres approches préconisées par les co-auteurs du Manifeste Agile telles que Scrum, le développement piloté par les tests (TDD), la programmation orientée objet (OOP) et les modèles de conception (par exemple, voir le post LinkedIn de Soumen Sarkar sur les modèles de conception ).

Je n'ai pas grand chose à ajouter dans ce domaine. Cependant, je me demande si les co-auteurs d'Agile n'avaient pas lutté si durement contre sa mort en tant que religion, si la communauté des ingénieurs logiciels aurait été plus clémente envers leurs autres idées. La question est désormais sans objet étant donné que le statut religieux d'Agile est la rigidité cadavérique et que tout semble à prendre : OOP, modèles de conception, TDD, etc.

Vers une prise de conscience de l'aversion aux pertes

Étant donné que j'ai passé une partie relativement considérable des derniers mois à faire la une de diverses publications technologiques parlant d'Agile et à être largement discuté au sein de la communauté en général, il ne serait peut-être pas surprenant d'avoir quelques rencontres bizarres. Pour la plupart, cependant, il s'agissait de rencontres extrêmement agréables de personnes venant vers moi en public et engageant au hasard une discussion sur Agile.

Il y a eu cependant une rencontre qui m'a laissé une forte impression. Il y a quelques semaines, je me rendais au Parlement britannique pour m'adresser aux décideurs politiques au sujet de divers scandales technologiques sur lesquels j'enquêtais. Je n'ai jamais été un grand fan du pouvoir, et j'ai toujours trouvé curieux que dans les bars privés du Parlement, il y ait des panneaux rappelant aux individus de ne pas abuser de leur pouvoir lorsqu'ils sont ivres.

Cependant, en donnant cette conférence, j'étais non seulement bien habillé et plus présentable que d'habitude, mais j'étais également devant un public sympathique, flanqué d'un député et d'un ami qui se trouve être conseiller du roi (un avocat chevronné à qui le monarque a accordé cette distinction pour son plaidoyer exceptionnel).

Un jour, j'ai donné ma conférence et répondu à un certain nombre de questions. Il y avait dans le public un visiteur qui a commencé à parler d'Agile (la conférence n'avait pas porté sur Agile). Contrairement à mon costume trois pièces, il était vêtu d'une chemise tachée de ketchup et (sans entrer dans les détails) n'était ni présentable ni politiquement connecté. Il a commencé à me demander : « Puis-je vous donner mon avis ? »

Lorsqu'il a commencé à parler d'Agile, je l'ai regardé dans les yeux d'un air interrogateur, il a baissé les yeux et s'est arrêté de parler, presque comme s'il réalisait qu'il n'était plus en ligne et qu'il avait réellement affaire à quelqu'un avec ses mots. Avant que je puisse répondre, un ami PDG est intervenu pour aborder le sujet à ma place.

À ce moment-là, j’ai réalisé que je n’aimais pas le pouvoir à un point que je n’avais pas réalisé jusqu’à présent.

Malheureusement, pour cet individu, il semble qu'il ait déjà été victime de ceux qui vendent des solutions de transformation infaillibles, ce qui semble avoir entraîné des difficultés dans sa propre vie. Dans ces circonstances, pourquoi ces méthodes de transformation sont-elles encore préconisées ?

Plus généralement, pourquoi l’Agile est-elle incapable de fonctionner dans le monde réel ? Avec le communisme, on peut au moins attribuer l’échec à la cupidité, alors quelle est la psychologie de l’échec de l’Agile ? La réponse, à mes yeux, se résume à un facteur psychologique connu sous le nom d’ aversion à la perte . À la demande générale, j’ai récemment rédigé un article pré-imprimé sur les travaux d’Impact Engineering et il se concentrait sur le rôle que la prise de conscience de l’aversion à la perte peut jouer dans l’atténuation du succès d’un projet.

L’article « So Am I Dr. Frankenstein? Or Were You a Monster All Time? »: Mitigating Software Project Failure With Loss-Aversion-Aware Development Methodologies (Suis-je donc le Dr Frankenstein ? Ou étiez-vous un monstre tout le temps ?) : Mitigation de l’échec des projets logiciels grâce à des méthodologies de développement tenant compte de l’aversion aux pertes , conclut comme suit :

Des études de cas ont montré que les désastres logiciels peuvent se transformer en catastrophes lorsque les problèmes ne sont pas traités et sont plutôt dissimulés. Des facteurs psychologiques, notamment l'aversion aux pertes, peuvent inciter les organisations à emprunter cette voie malgré les conséquences désastreuses.

Pourtant, les méthodologies logicielles ont historiquement ignoré ce facteur psychologique, partant du principe que les humains voudront résoudre les problèmes le plus tôt possible. Des recherches antérieures sur diverses méthodologies ont montré que la sécurité psychologique nécessaire pour soulever et discuter des problèmes est essentielle pour améliorer la livraison de logiciels. Cependant, il est sans doute optimiste de croire qu'un changement culturel et psychologique aussi important peut être réalisé dans toutes les organisations. Comme nous le constatons, même entre le Royaume-Uni et les États-Unis, la sécurité psychologique reste la plus grande différence dans les pratiques d'ingénierie entre les deux pays.

Dans cet article, nous nous concentrons sur une autre voie à suivre. Au lieu de tenter de réaliser un changement culturel qui est au mieux un défi, nous nous concentrons plutôt sur une approche plus pragmatique : limiter les déclencheurs d’aversion aux pertes dès le départ en établissant des exigences solides, puis viser la sécurité psychologique là où elle est nécessaire. Dans nos recherches, le seul facteur que nous avons trouvé qui augmenterait le taux de réussite d’un projet plus que la sécurité psychologique était d’avoir des exigences claires dès le départ.

Contrairement à notre hypothèse, les résultats montrent que le simple fait d’avoir des exigences claires, même si elles changent en fin de développement ou ne sont pas alignées avec le monde réel, semble jouer un rôle important dans la réussite d’un projet logiciel. Cela suggère que le fait d’avoir une porte avant le début d’un projet pour discuter et résoudre les problèmes, lorsque l’aversion aux pertes est à son plus bas, permet la plus grande amélioration des taux de réussite.

La chanson Dr. Frankenstein de RedHook contient le refrain : « So am I Dr. Frankenstein? Or were you a monster all the time ? » Pour les projets logiciels catastrophiques, cet article soutient que les projets logiciels deviennent des désastres lorsque les humains ne parviennent pas à résoudre les problèmes techniques à petite échelle. Les méthodologies d'ingénierie logicielle existantes ne tiennent pas compte du fait que les humains ne sont pas des machines et que des facteurs psychologiques entravent la capacité à résoudre les problèmes. Après avoir identifié cet anachronisme dans les méthodologies existantes, cet article présente comment nous pouvons agir en utilisant des exigences avant le début d'un projet pour donner la possibilité de résoudre les problèmes lorsque l'aversion aux pertes est à son plus bas.