Méthodes et pratiques

L'agilité à l'échelle

Le Manifeste de 2001 parle d'une équipe. Il ne dit rien de ce qu'il faut faire quand un produit en mobilise douze, cinquante ou deux cents. Plusieurs cadres dits « à l'échelle » proposent de combler ce silence, et le plus célèbre d'entre eux, le « modèle Spotify », n'a jamais été présenté comme un modèle à copier par ceux qui l'ont décrit.

Ce qui change quand les équipes se multiplient

Imaginez une équipe de sept personnes qui développe l'application d'une mutuelle. Tout le monde se connaît, les questions se règlent en traversant la pièce et l'ensemble du travail tient sur un seul tableau. Trois ans plus tard, douze équipes travaillent sur l'application, soit 84 personnes. Entre sept personnes, il existe 21 relations possibles deux à deux. Entre 84 personnes, il y en a 3 486. Frederick Brooks faisait déjà ce calcul dans The Mythical Man-Month (1975) pour expliquer qu'ajouter des gens à un projet en retard le retarde encore.

Les difficultés nouvelles tiennent d'abord aux dépendances, puisque l'équipe qui construit l'écran de remboursement doit attendre celle qui fournit les données des contrats. Elles tiennent aussi à l'intégration, c'est-à-dire à l'assemblage régulier du travail de tous en un seul produit qui fonctionne. Il faut enfin décider des priorités pour le produit entier, et non plus équipe par équipe.

Le Manifeste ne traite aucune de ces questions. Ses principes raisonnent à l'échelle d'une équipe de développement et de ses interlocuteurs. Le onzième affirme :

Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées.

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

Le texte ne dit pas comment une architecture commune peut émerger de douze équipes à la fois. La première réponse est venue de Scrum, le cadre agile le plus répandu (voir Scrum en bref). Jeff Sutherland a décrit en 2001, à partir de son expérience dans la société IDX, le « Scrum de Scrums » : chaque équipe envoie un représentant à une courte réunion de coordination, où l'on traite les dépendances et les obstacles communs. Les cadres apparus dans les années 2010 proposent une organisation plus complète.

Quatre cadres, deux manières de voir

SAFe est le plus volumineux des quatre, et sans doute le plus diffusé dans les grandes entreprises. Son unité de base est le « train de livraison agile », qui réunit de cinq à douze équipes. Tous les deux à trois mois, les 50 à 125 personnes du train se retrouvent pendant deux jours pour planifier ensemble la période suivante, lors d'un événement appelé PI Planning. Au-dessus du train, d'autres niveaux traitent les grands programmes et le portefeuille des investissements. Le cadre est édité par une société, Scaled Agile, qui vend des formations et des certifications.

LeSS prend le parti inverse. Craig Larman et Bas Vodde, qui l'ont tiré de leur travail auprès de grandes entreprises, dont l'équipementier de télécommunications Nokia Networks, se demandent d'abord de quoi l'on peut se passer. Jusqu'à huit équipes partagent un seul backlog, c'est-à-dire la liste ordonnée de tout ce qui reste à faire, et un seul Product Owner, la personne qui décide des priorités. Elles produisent ensemble un seul incrément à la fin de chaque sprint : une version du produit complète et utilisable, obtenue au terme d'un cycle de travail d'un mois au plus. Chaque équipe doit pouvoir réaliser une fonctionnalité de bout en bout sans attendre les autres.

Nexus ajoute surtout à Scrum une équipe chargée de veiller à ce qu'un incrément commun et terminé existe à chaque sprint. Scrum@Scale généralise le Scrum de Scrums : les représentants des équipes forment une équipe de niveau supérieur, et ainsi de suite jusqu'aux dirigeants, qui lèvent les obstacles et arbitrent les priorités de l'ensemble. SAFe coordonne donc une grande organisation telle qu'elle est, en lui ajoutant des rôles et des niveaux. LeSS et Nexus cherchent plutôt à réduire le besoin de coordination en réorganisant le travail autour d'un seul produit.

Le « modèle Spotify », un instantané devenu modèle

En octobre 2012, Henrik Kniberg et Anders Ivarsson, tous deux coachs agiles chez Spotify, publient un document de quatorze pages intitulé « Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds ». L'entreprise compte alors plus de trente équipes réparties dans trois villes, et son effectif technique est passé de 30 à 250 personnes en trois ans. Le document décrit quatre formes de regroupement :

• la squad est une petite équipe comparable à une équipe Scrum, chargée d'une mission durable et libre de choisir sa méthode de travail ;
• la tribu rassemble les squads d'un même domaine, sans dépasser une centaine de personnes ;
• le chapitre réunit, au sein d'une tribu, les personnes d'un même métier, et son responsable est leur supérieur hiérarchique ;
• la guilde est une communauté d'intérêt ouverte à tous, qui traverse toute l'entreprise.

Le document s'ouvre sur un avertissement que ses lecteurs ont peu retenu. Kniberg et Ivarsson écrivent qu'ils n'ont pas inventé ce modèle, que leur article n'est qu'un instantané de leur manière de travailler du moment et que les choses auront déjà changé quand on le lira. Ils précisent en conclusion que cette organisation a été introduite au cours de l'année écoulée et que les salariés s'y habituent encore.

Kniberg a diffusé en 2014 deux vidéos sur la culture d'ingénierie de Spotify, et l'ensemble a pris dans la profession le nom de « modèle Spotify ». Il a répété depuis qu'il avait seulement décrit le fonctionnement d'une entreprise à un moment donné, sans intention d'en faire un cadre à copier. De nombreuses entreprises ont pourtant rebaptisé leurs équipes en squads et leurs départements en tribus.

En 2020, Jeremiah Lee, entré chez Spotify comme chef de produit à la fin des années 2010, a publié un article intitulé « Spotify's Failed #SquadGoals ». Selon lui, l'organisation décrite en 2012 relevait en partie de l'aspiration et n'a jamais été complètement appliquée. Il décrit des squads autonomes mais dépourvues de règles communes pour collaborer entre elles, et des responsables hiérarchiques extérieurs aux équipes, mal placés pour arbitrer leurs conflits. Ce témoignage, qui cite aussi d'anciens collègues, reste un point de vue individuel, mais il concorde avec les mises en garde des auteurs.

Les critiques venues des signataires

Les critiques les plus vives de ces cadres viennent de signataires du Manifeste. En août 2013, Ken Schwaber publie un billet intitulé « unSAFe at any speed ». Il y présente SAFe comme le retour des promoteurs du Rational Unified Process, une méthode de la fin des années 1990 qui a selon lui échoué, et lui reproche de proposer à toutes les organisations une solution unique centrée sur le processus, à rebours de la première valeur du Manifeste :

Les individus et leurs interactions plus que les processus et les outils

Manifeste pour le développement agile de logiciels (2001), texte intégral

Schwaber n'est pas un observateur neutre : il a fondé Scrum.org, qui publiera son propre cadre, Nexus, deux ans plus tard.

Ron Jeffries a suivi la formation de consultant SAFe avant d'écrire, en février 2014, un article au jugement plus nuancé, « SAFe - Good But Not Good Enough ». Il y reconnaît des qualités réelles, dont des repères clairs pour les grandes organisations et une attention affirmée à la qualité du code, et il prévoit que les entreprises qui adoptent SAFe s'amélioreront. Il juge pourtant que le cadre n'est pas agile dans son esprit, parce que la planification y descend du sommet et laisse peu de place à l'initiative des équipes. Il conteste aussi l'idée qu'une organisation doive tout coordonner à grande échelle du seul fait qu'elle est grande. L'article Être agile ou faire de l'agile replace ces critiques dans un débat plus large sur les processus imposés.

Les défenseurs de SAFe répondent que les grandes organisations ne partent pas d'une page blanche. Une banque a des budgets annuels, des obligations réglementaires et des milliers de salariés habitués à une hiérarchie. Un cadre détaillé leur donne un point de départ que les principes seuls ne fournissent pas. L'argument est sérieux. Il laisse ouverte la question de savoir si ce point de départ conduit ensuite à davantage d'autonomie pour les équipes ou s'il fige l'organisation dans un nouveau processus.

Coordonner ou découpler

Le choix entre ajouter de la coordination et réduire les dépendances se pose dans toute grande organisation, bien au-delà de l'informatique.

Melvin Conway a observé dès 1968 qu'une organisation conçoit des systèmes dont la structure reproduit ses propres circuits de communication. Douze équipes qui doivent sans cesse se coordonner signalent souvent un produit mal découpé. Le remède se trouve alors dans l'architecture du produit et dans la composition des équipes, avant de se trouver dans un cadre.

Que sait-on de leur efficacité ?

Les éditeurs de ces cadres publient des études de cas flatteuses, qui prouvent peu de chose : les échecs ne sont pas publiés, et rien ne dit ce qui se serait passé sans le cadre. La recherche indépendante reste mince. En 2016, Kim Dikert, Maria Paasivaara et Casper Lassenius ont passé en revue les publications consacrées aux transformations agiles de grande taille. Près de neuf sur dix étaient des retours d'expérience, et non des études conduites selon une méthode scientifique.

À notre connaissance, aucune comparaison rigoureuse ne permet aujourd'hui de dire qu'un cadre fait mieux qu'un autre, ni qu'une grande organisation réussit mieux avec un cadre que sans. L'article Que valent les preuves ? replace ce constat dans l'ensemble des connaissances disponibles.

Limites et pièges

Passer à l'échelle sans nécessité. Beaucoup de produits peuvent être construits par quelques équipes, et un grand produit peut parfois être découpé en plusieurs produits indépendants. Avant de coordonner cinquante équipes, il vaut la peine de vérifier que le travail en demande autant.

Changer les mots sans changer les pouvoirs. Appeler « squad » un service et « tribu » une direction ne modifie rien si les priorités, les budgets et les méthodes continuent d'être fixés ailleurs. Copier Spotify revient en outre à copier la photographie, prise en 2012, d'une entreprise qui s'est elle-même éloignée de cette organisation depuis.

Refaire un plan rigide tous les trimestres. Une planification commune détaillée peut redevenir un plan que l'on suit coûte que coûte, alors que le Manifeste valorise « L’adaptation au changement plus que le suivi d’un plan ».

Prendre la certification pour une compétence. Un certificat atteste qu'une personne a suivi un cours et connaît un vocabulaire. Il ne dit pas si son organisation livre mieux qu'avant.