Histoire de l’agilité : de Royce au Manifeste, et au-delà

Scène fréquente. Un comité de direction annonce que l’entreprise « passe en agile ». Six mois plus tard, les équipes ont des sprints, des réunions quotidiennes et des tableaux couverts de post-it. Les arbitrages, eux, attendent toujours le comité trimestriel. Pour comprendre ce décalage, il faut revenir à l’histoire de l’agilité.

Elle ne commence pas en 2001. Elle ne parle pas d’abord de rituels. Elle raconte des praticiens qui voulaient apprendre plus vite que leurs plans ne vieillissaient.

Cet article retrace ce parcours avec des dates vérifiées et sourcées. On y croise l’article de Winston Royce en 1970 et la mêlée de Takeuchi et Nonaka en 1986. Suivent la présentation de Scrum en 1995 et le Manifeste de Snowbird en 2001. Viennent ensuite les guides, la méthode Kanban, le passage à l’échelle et les dérives dénoncées par les auteurs du Manifeste eux-mêmes. À chaque étape, une question guide la lecture : qu’est-ce que cela change pour une équipe qui veut décider et livrer autrement ?

En août 1970, Winston W. Royce publie « Managing the Development of Large Software Systems » dans les actes de la conférence IEEE WESCON. On le présente souvent comme le père du modèle en cascade. C’est un contresens documenté. Royce juge risqué un processus qui enchaîne les étapes sans revenir en arrière. Il recommande de parcourir le cycle au moins deux fois. Il n’emploie même pas le mot « waterfall », apparu plus tard dans la littérature.

L’industrie avance sur une piste parallèle. Le système de production de Toyota repose sur deux piliers. Le jidoka arrête la ligne dès qu’une anomalie apparaît, pour ne pas fabriquer de produits défectueux. Le juste-à-temps ne produit que ce qui est nécessaire, au moment nécessaire. Toyota présente le kaizen, l’amélioration continue, comme une pratique quotidienne de tous ses employés.

En janvier 1986, Hirotaka Takeuchi et Ikujiro Nonaka publient « The New New Product Development Game » dans la Harvard Business Review. Ils y opposent l’approche séquentielle, en relais, à une approche où l’équipe avance ensemble, comme au rugby. Cette métaphore de la mêlée, le scrum, vise alors le développement de produits industriels. Le logiciel la reprendra près de dix ans plus tard.

Ce que retient un facilitateur de cette préhistoire : l’agilité répond d’abord à l’incertitude. Quand un problème est simplement compliqué, un plan détaillé fonctionne. Quand il est complexe, seul le retour du terrain dit si l’on avance. C’est toute la différence entre un problème compliqué et un problème complexe, et elle explique pourquoi l’itération s’est imposée.

Les années 1990 voient naître ce que l’on appelle alors les méthodes « légères ». Leur point commun tient en une opposition : elles refusent les processus lourds, pilotés par la documentation, qui figent le projet avant qu’il ait appris quoi que ce soit.

Extreme Programming plonge ses racines dans la collaboration de Kent Beck et Ward Cunningham, à la fin des années 1980. Selon Martin Fowler, Beck affine ses pratiques sur le projet C3 de Chrysler et emploie le terme « extreme programming » vers 1997.

Scrum sort de l’ombre en 1995. Ken Schwaber et Jeff Sutherland le présentent à la conférence OOPSLA et y publient sa première définition formelle. L’idée de la mêlée de 1986 change de terrain : de l’usine au logiciel.

Martin Fowler résume l’esprit de ces méthodes en deux glissements. Elles sont adaptatives plutôt que prédictives : elles accueillent le changement au lieu de lui résister. Elles sont orientées vers les personnes plutôt que vers le processus : aucun processus ne remplace les compétences d’une équipe, donc le processus doit la servir. Ces deux phrases restent le meilleur test pour savoir si une organisation pratique l’agilité ou son décor.

Du 11 au 13 février 2001, dix-sept personnes se retrouvent au Lodge at Snowbird, dans les montagnes de l’Utah. Elles représentent Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development et Pragmatic Programming. Le récit de la rencontre, écrit par Jim Highsmith, précise un détail savoureux : Martin Fowler fut le seul à émettre une réserve sur le mot « agile ».

Le texte signé porte le titre de Manifeste pour le développement agile de logiciels. Ses auteurs sont Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland et Dave Thomas.

Ses quatre valeurs privilégient :

• les individus et leurs interactions, plus que les processus et les outils ;
• des logiciels opérationnels, plus qu’une documentation exhaustive ;
• la collaboration avec les clients, plus que la négociation contractuelle ;
• l’adaptation au changement, plus que le suivi d’un plan.

La phrase qui suit est la plus souvent oubliée. Les auteurs écrivent : « Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers. » Le Manifeste ne dit donc pas qu’il faut jeter le plan. Il dit qu’un plan ne doit pas empêcher de s’adapter. Les douze principes sous-jacents au Manifeste détaillent cette posture, jusqu’à la réflexion régulière de l’équipe sur sa propre efficacité.

Après la réunion, les participants se désignent comme l’Agile Alliance. D’après Martin Fowler, ils décident plus tard dans l’année de ne pas constituer d’organe dirigeant. L’Agile Alliance devient ensuite une organisation à but non lucratif.

Après 2001, le mouvement se codifie. Ken Schwaber et Jeff Sutherland rédigent le premier Scrum Guide en 2010. La version de novembre 2020 fait référence aujourd’hui. Elle définit Scrum comme un cadre de travail léger. Ce cadre aide des personnes, des équipes et des organisations à créer de la valeur par des solutions adaptatives à des problèmes complexes. Le mot « léger » compte : le guide présente Scrum comme volontairement incomplet. Il ajoute que le cadre se construit grâce à l’intelligence collective de ceux qui l’utilisent, une phrase qu’un facilitateur aurait pu écrire.

La même année 2010, David J. Anderson publie « Kanban: Successful Evolutionary Change for Your Technology Business ». Le guide de Kanban University s’appuie sur ce livre. Il décrit la méthode Kanban comme une approche à appliquer sur un processus existant, pour rendre visible un travail intellectuel invisible. Elle plonge ses racines dans le Lean.

Le troisième chantier porte sur l’échelle. Quand des dizaines d’équipes travaillent sur un même produit, des cadres comme SAFe ou LeSS proposent de coordonner les cadences et les priorités. Ils répondent à un vrai besoin et soulèvent de vraies objections, que nous détaillons dans notre article sur le Scaled Agile Framework, ou SAFe.

Dans le même temps, l’agilité sort du logiciel. Les formations d’initiation s’adressent désormais aussi à des RH, des commerciaux ou des équipes marketing. Pour une équipe RH qui traite des demandes de recrutement en flux continu, visualiser le travail en cours peut avoir plus de sens que découper l’année en sprints.

Dix ans après Snowbird, le constat vient de l’intérieur. En juillet 2011, Dave West publie chez Forrester un rapport intitulé « Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today ». Sa thèse : la pratique s’est éloignée des idées du Manifeste. Le nom dit le modèle : de la cascade en amont, du Scrum au milieu, de la cascade en aval. Le rapport ne juge pas ce modèle forcément mauvais, mais il exige d’en piloter les frontières.

En mars 2014, Dave Thomas, signataire du Manifeste, publie « Agile is Dead (Long Live Agility) ». Il constate que le mot est devenu une marque, exploitée par des vendeurs de formations, d’outils et de conseil. Il propose de parler plutôt d’« agilité » : un label s’achète, l’expérience se gagne avec le temps. Il résume cette agilité en quatre étapes.

Ron Jeffries, autre signataire, va plus loin dans un texte intitulé « Developers Should Abandon Agile ». Il y décrit un « faux agile » imposé par le haut : plus d’interruptions, moins de temps, plus de pression. Il conseille aux développeurs de revenir aux pratiques et aux valeurs du Manifeste, quelle que soit la méthode imposée par l’organisation.

Sur le terrain, trois erreurs reviennent plus souvent que les autres :

• Installer les cérémonies sans toucher aux décisions. Les équipes font des sprints, mais le budget, les priorités et les arbitrages restent annuels. C’est le water-Scrum-fall décrit par Forrester.
• Lire le Manifeste comme un rejet du plan. Le texte reconnaît la valeur des plans et de la documentation. Supprimer toute planification n’est pas de l’agilité, c’est du pilotage à vue.
• Transformer la rétrospective en bureau des plaintes. Sans cadre, le moment d’apprentissage devient une liste de griefs. Sans décision qui en sorte, l’équipe cesse d’y croire.

Ces dérives nourrissent les chiffres alarmistes sur l’échec des transformations. Le plus cité, celui de 70 % d’échecs, est en réalité contesté. Nous avons examiné ce qu’il vaut dans notre analyse du chiffre des 70 % de transformations qui échouent.

Chez Insuffle, cabinet de facilitation stratégique qui accompagne des équipes de direction, nous lisons cette histoire comme une leçon de posture plus que de méthode. Les dix-sept auteurs n’ont pas écrit un catalogue de rituels. Ils ont décrit des conditions pour apprendre vite : des personnes qui se parlent, un résultat concret à regarder, un client présent, un plan qui accepte d’être corrigé.

Pour un dirigeant, la question n’est donc pas « faut-il adopter Scrum ? ». Elle est de savoir si le comité de direction décide lui-même par petits pas. Prenons une PME industrielle qui lance des équipes agiles côté produit. Si le CODIR continue d’arbitrer une fois par trimestre, les sprints de deux semaines buteront sur ses décisions. Le changement commence en haut, et il se construit dans la durée, comme dans un accompagnement de la transformation qui dépasse le séminaire ponctuel.

Pour un praticien, cette histoire rappelle que le Scrum Master est d’abord un facilitateur. Le Scrum Guide 2020 lui confie le soin d’aider l’équipe et l’organisation à progresser, et de faciliter la collaboration avec les parties prenantes. Trois conseils applicables dès la prochaine itération :

1. Ouvrez la rétrospective sur un fait, ce qui a été livré et utilisé, avant toute opinion.
2. Limitez le nombre de sujets en cours : Ron Jeffries conseille de terminer des éléments complets plutôt que de tout commencer.
3. Appliquez la règle de Dave Thomas : à valeur égale, choisissez l’option qui rend le prochain changement plus facile.

Pour pratiquer ces gestes en situation, Insuffle Académie, la branche organisme de formation d’Insuffle certifiée Qualiopi, propose deux parcours en présentiel, finançables par les OPCO. Les fondamentaux de l’agilité se vivent en une journée, avec une simulation Scrum et un repérage du « théâtre agile ». La formation Scrum Master dure deux jours et travaille la facilitation et le coaching d’équipe.

De Royce à Dave Thomas, le fil est le même. Les gens qui ont fait l’agilité cherchaient à réduire l’écart entre ce que l’on croit et ce que le terrain montre. Les rituels sont venus ensuite, utiles tant qu’ils servent cet apprentissage, nuisibles dès qu’ils le remplacent.

Avant d’ajouter un sprint, une cérémonie ou un outil, posez une seule question à votre équipe : qu’avons-nous appris le mois dernier qui a changé une décision ? Si personne ne trouve de réponse, le problème n’est pas la méthode. C’est la boucle qui ne tourne pas, et c’est là qu’un regard de facilitateur aide le plus.