Perspectives et limites

Être agile ou faire de l'agile

Une équipe peut tenir toutes les réunions prévues par une méthode agile sans jamais rien livrer d'utile à personne. La distinction entre « faire de l'agile » et « être agile » désigne cet écart. Les critiques les plus sévères de cette dérive ont été écrites par des signataires du Manifeste, qui ne reconnaissent plus leur texte dans ce qui se vend sous son nom.

Une équipe agile sur le papier

Cette équipe a le vocabulaire et les réunions d'une méthode agile. Pourtant aucun utilisateur ne voit le logiciel avant la fin de l'année, et le plan fixé en janvier ne change pas. On dit dans la profession qu'elle « fait de l'agile » sans « être agile ». La première expression désigne l'adoption des formes. La seconde désigne une capacité réelle à livrer souvent et à changer de direction d'après les retours des utilisateurs. La formule, courante, n'a pas d'auteur attitré. Elle a aussi ses défauts, sur lesquels on reviendra.

Quatre signataires, un même diagnostic

Entre 2006 et 2018, quatre des dix-sept signataires du Manifeste ont décrit cette dérive, sans renier le texte de 2001.

Dave Thomas : garder l'adjectif

Dave Thomas, coauteur de The Pragmatic Programmer (1999) avec Andy Hunt, publie le 4 mars 2014 un billet intitulé « Agile is Dead (Long Live Agility) ». Son constat est que le mot « agile » a été détourné au point de ne plus rien vouloir dire. Il sert selon lui d'étiquette à des consultants et à des vendeurs d'outils, et un mot devenu marque cesse de porter un sens.

Thomas rappelle les quatre valeurs du Manifeste et propose d'en résumer la pratique en quelques gestes : savoir où l'on en est, faire un petit pas vers son but, corriger sa compréhension d'après ce que l'on vient d'apprendre, puis recommencer. Quand deux options se valent, il conseille de choisir celle qui rendra les changements futurs plus faciles. Sa proposition la plus connue est grammaticale. « Agile » est un adjectif, qui doit qualifier quelque chose, et l'on en a fait un nom, puis un produit que l'on achète. Thomas suggère de lui préférer le nom « agilité » : on ne serait plus un « programmeur agile », on programmerait avec agilité.

Andy Hunt : des règles suivies à la lettre

Andy Hunt publie le 6 mai 2015 « The Failure of Agile ». Il y avance deux explications. Un débutant, dans n'importe quel domaine, a besoin de règles concrètes et ne sait pas encore manier une consigne abstraite comme « inspecter et adapter ». Beaucoup d'équipes en restent donc aux règles et les appliquent à la lettre. Les méthodes agiles, ajoute-t-il, n'ont pas été agiles elles-mêmes, puisque leurs pratiques de référence n'ont presque pas changé en plus de dix ans. Hunt propose alors une nouvelle démarche, baptisée GROWS, qui adapte les consignes au niveau d'expérience de chacun.

Ron Jeffries : le « Scrum sombre »

Ron Jeffries, l'un des fondateurs d'Extreme Programming, publie le 8 septembre 2016 un article intitulé « Dark Scrum ». Il précise d'emblée que Scrum, même appliqué passablement, est un bon cadre, puis décrit ce qu'il devient quand ceux qui détiennent le pouvoir dans l'entreprise s'en servent sans en comprendre l'esprit. La réunion quotidienne leur donne l'occasion de surveiller l'équipe chaque jour. La planification du sprint sert à lui imposer une charge de travail, la revue à lui reprocher ce qui n'est pas fini et la rétrospective à lui expliquer comment elle doit s'améliorer. Jeffries s'adresse aux développeurs et leur donne un conseil technique : produire à chaque sprint un incrément, c'est-à-dire une version du logiciel testée, intégrée et réellement utilisable, grâce aux tests automatisés, au refactoring et à l'intégration continue (voir Les pratiques d'ingénierie).

Le 10 mai 2018, il va plus loin dans « Developers Should Abandon Agile ». Le titre est trompeur si on le lit seul. Jeffries distingue l'agilité du Manifeste de ce qu'il écrit « Agile » entre guillemets, c'est-à-dire l'ensemble des démarches qui se réclament du mot sans toujours en respecter l'esprit. Il constate que ces démarches, mal appliquées, valent aux développeurs davantage d'ingérence et de pression, avec moins de temps pour travailler. Il leur conseille donc de se détacher des méthodes qu'on leur impose et de s'en tenir à quelques pratiques, quel que soit le cadre : produire toutes les deux semaines, ou plus souvent, un logiciel testé et intégré, garder une conception propre et s'appuyer sur ce logiciel pour discuter des priorités avec leur hiérarchie. Il écrit dans le même article que les valeurs et les principes du Manifeste restent la meilleure manière qu'il connaisse de construire des logiciels.

Martin Fowler : le « complexe agilo-industriel »

Martin Fowler avait donné dès 2006 un nom au phénomène : la « diffusion sémantique ». Un mot forgé par un petit groupe, avec une définition assez précise, voit son sens s'affaiblir à mesure qu'il se répand, au risque de devenir inutilisable. Fowler citait déjà « agile » en exemple. En 2009, il décrit le « Scrum flasque » (Flaccid Scrum) : une équipe adopte les pratiques de Scrum, néglige la qualité technique et voit sa progression ralentir parce que son code est devenu inextricable. Fowler n'en accuse pas Scrum, qui laisse la technique hors de son champ. Il recommande de lui adjoindre des pratiques comme celles d'Extreme Programming.

En août 2018, il publie le texte d'une conférence donnée à Melbourne, « The State of Agile Software in 2018 ». Une grande partie de ce qui se pratique sous le nom d'agile est selon lui du « faux agile », qui tourne le dos aux valeurs et aux principes. Il désigne trois chantiers. Le premier est de combattre ce qu'il appelle le « complexe agilo-industriel » (Agile Industrial Complex), c'est-à-dire les cabinets et les organismes qui vendent des processus tout faits et les imposent aux équipes. Pour Fowler, il n'existe pas de méthode unique valable pour tous les logiciels, et c'est à l'équipe qui fait le travail de décider comment le faire. Le deuxième chantier est de redonner sa place à l'excellence technique. Le troisième est d'organiser le travail autour de produits durables plutôt que de projets temporaires.

Ce que dit le texte

Ces reproches s'appuient sur le Manifeste lui-même, dont la première valeur s'énonce « Les individus et leurs interactions plus que les processus et les outils ». Le cinquième principe demande de faire confiance à l'équipe :

Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.

Principes sous-jacents au Manifeste agile (2001), texte intégral

Le neuvième principe répond d'avance au « Scrum flasque » : « Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité. » Le Manifeste ne condamne pas les processus pour autant. Sa dernière phrase est : « Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. » Les signataires reprochent à l'industrie d'avoir inversé cet ordre.

Certifications et culte du cargo

Le commerce que visent ces critiques a une forme précise, la certification. La Scrum Alliance, créée en 2002 par Ken Schwaber avec d'autres praticiens, dont Mike Cohn, délivre le titre de Certified ScrumMaster à l'issue de seize heures de formation, suivies d'un test de cinquante questions à choix multiples auquel il faut obtenir trente-sept bonnes réponses. Schwaber a quitté l'organisation en 2009, après un désaccord qui portait notamment sur la certification, et il a fondé Scrum.org, qui délivre ses propres certificats. Les cadres destinés aux grandes organisations ont aussi les leurs (voir L'agilité à l'échelle).

Un certificat de ce genre atteste qu'une personne a suivi un cours et en a retenu le vocabulaire. Il ne dit rien de sa capacité à aider une équipe. La difficulté vient des entreprises qui recrutent sur certificat, puis comptent les certifiés pour mesurer l'avancement d'une « transformation agile ». Un indicateur devenu objectif cesse de renseigner sur ce qu'il mesurait : c'est la loi de Goodhart, qui vaut aussi pour la vélocité affichée au mur.

Le physicien Richard Feynman a donné un nom à cette confusion entre la forme et le fond. Dans un discours aux étudiants de Caltech, en 1974, il raconte que des habitants d'îles du Pacifique, qui avaient vu pendant la guerre des avions débarquer des marchandises, ont ensuite aménagé des pistes, allumé des feux pour les baliser et installé un homme dans une cabane avec des écouteurs en bois. La forme était parfaite, et aucun avion ne se posait. Feynman appelait « science du culte du cargo » les travaux qui imitent les apparences de la science sans sa rigueur. Steve McConnell a repris l'image en 2000 à propos des organisations qui copient les procédures d'entreprises de logiciel admirées sans comprendre ce qui les rend efficaces.

Des critères que l'on peut observer

La distinction entre faire et être ne sert à rien si elle reste une affaire d'impression. En octobre 2018, le Defense Innovation Board, un comité consultatif du département américain de la Défense, a publié un guide de quelques pages intitulé « Detecting Agile BS ». Il veut aider les responsables qui achètent du logiciel à distinguer les projets réellement agiles des projets traditionnels habillés du nouveau vocabulaire. Parmi les signaux d'alerte figure le fait de tenir le respect des exigences initiales pour plus important que la mise rapide de quelque chose d'utile entre les mains des utilisateurs. La question centrale du guide est de savoir si les équipes livrent un logiciel qui fonctionne à de vrais utilisateurs à chaque itération (chaque cycle de travail), y compris la première, et si elles recueillent leurs retours.

Limites et pièges de cette critique

Un argument qui ne peut pas perdre. Si chaque échec est attribué à un « faux agile », l'agilité véritable ne peut jamais être prise en défaut, et l'affirmation qu'elle fonctionne devient invérifiable. La seule issue est de définir à l'avance des critères observables, puis de mesurer. L'article Que valent les preuves ? montre que ce travail a rarement été fait.

Des critiques qui sont aussi des acteurs du marché. Thomas et Hunt ont fondé une maison d'édition de livres techniques, Jeffries a longtemps formé des équipes et Fowler travaille pour une société de conseil en logiciel. La critique garde sa valeur, et il faut savoir qu'elle vient de l'intérieur du marché qu'elle dénonce.

Un point de vue de petites équipes expertes. Les signataires étaient pour la plupart des programmeurs chevronnés, habitués à des équipes réduites (voir Les dix-sept signataires). Une banque qui emploie des milliers de développeurs et doit respecter des obligations réglementaires ne peut pas laisser chaque équipe réinventer sa méthode sans aucun cadre commun. Dénoncer les processus imposés ne dit pas ce qu'il faut faire à cette échelle.

Les formes ont leur utilité. Hunt le reconnaît lui-même : un débutant a besoin de règles. Tenir une réunion quotidienne et une rétrospective avant d'en comprendre toute la portée est une manière raisonnable de commencer, à condition d'examiner ensuite ce que ces réunions produisent.

« Être agile » peut devenir un slogan à son tour. Quand l'agilité est présentée comme un état d'esprit, personne ne peut vérifier qui le possède, et le reproche de ne pas l'avoir retombe facilement sur les équipes. Les questions de l'encadré ci-dessus portent sur des faits pour cette raison.