Agilité à l'échelle, ce qu'il vous faut vraiment savoir

Article

Introduction

J'ai piloté ou observé une quinzaine de trains SAFe au fil des années. Pas tous couronnés de succès. Ce que je vois se répéter, c'est une illusion, celle que passer de Scrum classique à un framework d'échelle suffira. Ça ne suffit jamais. L'agilité d'équipe repose sur un petit nombre de variables maîtrisables. L'agilité d'échelle en dépend mille fois plus de contexte, de sponsor, d'alignement stratégique, et de la compétence d'une poignée de personnes qui vous l'auront compris.

Les gourous SAFe vous diront que c'est SAFe ou rien. Les sceptiques vous diront que c'est un apparat coûteux de cérémonies sans valeur. Les deux se trompent. L'agilité à l'échelle n'est ni une recette ni une religion. C'est un langage, une discipline, et un ensemble de leviers. Et ceux qui la maîtrisent ne sont jamais ceux qui ont lu le plus. Ils sont ceux qui ont vu le plus, qui ont fait échouer, qui en ont tiré des leçons précises.

Ce texte repose sur ce que j'ai observé depuis mon poste de RTE, puis de coach en transformation, sans aucune charge commerciale pour vendre un framework plutôt qu'un autre.

Pourquoi l'agilité d'équipe ne suffit plus au-delà de 50 personnes

Scrum tient debout parce qu'une équipe est une entité cohérente. Un product backlog, un sprint, une vélocité, une rétro où chacun se voit deux fois par semaine. À quinze, vingt personnes bien soudées, Scrum marche. C'est un équilibre fragile, mais il marche.

Passez à quatre équipes, cinquante-quatre personnes. Soudain, le système se fissure.

D'abord, l'alignement se volatilise. Quatre PO différents, quatre priorisations différentes, quatre backlogs sans lien de cause à effet. Vous croyez livrer un produit cohérent, vous livrez une addition de features qui vont peut-être à contresens l'une de l'autre. Le PO général qui parle à la direction découvre qu'aucune des quatre équipes n'a compris la stratégie du trimestre.

Puis viennent les dépendances inter-équipes. L'équipe A a besoin d'une API de l'équipe B. L'équipe C attend un schéma de données de l'équipe D. Ces dépendances ne sont pas négligeables, elles sont nombreuses, cachées, et découvertes en sprint review. Résultat, la capacité prédite tombe à 40 % de la réalité. Vous naviguez à vue.

Ensuite, le rythme s'émiette. Quatre équipes en itération de deux semaines, ça fait quatre phases lunaires différentes. Quand faut-il synchroniser ? Qui parle à qui, quand ? Pas d'événement de cadrage commun, donc pas d'énoncé partagé de ce qu'on livre. Les escalades s'accumulent, et elles arrivent tard, au moment où il est trop tard pour replanifier.

J'ai vécu cela sur un grand compte industriel avant qu'on structure le premier train. Quatre équipes Scrum, une direction produit perdue, des livraisons déphasées. La capacité réelle était 35 % de la capacité contractée. On livrait lentement, sans fiabilité, et chacun avait une version de la vérité.

Ce qui casse, donc, ce n'est pas l'agile en lui-même. C'est l'absence de synchronisation, d'alignement intentionnel, et de visibilité partagée sur les dépendances.

Les trois familles de réponses, forces et angles morts

SAFe et ses vraies qualités. SAFe fournit exactement ça, un langage commun, un rythme cadencé, et un cadrage stratégique. Tout le monde parle d'ART (Agile Release Train), de Program Increment (PI), de PI Planning, de RTE. Pas besoin de réinventer la roue du cadrage tous les trois mois. C'est un atout.

SAFe oblige aussi le sponsor dans la salle. Le Product Manager n'est pas un PO au sens Scrum classique. C'est quelqu'un qui répond à la stratégie d'une ligne produit, qui met les mains dans les roadmaps, et qui donne la direction globale. Un PI Planning sans sponsor, c'est une journée de débat interne. Avec le sponsor, c'est une journée où on reçoit la contrainte réelle.

Les zones d'ombre. SAFe crée un apparat. PI Planning avec 150 personnes dans une salle, ou sur Zoom, ça demande une discipline de fer. Les rituels, quand personne ne les pilote vraiment, deviennent des cases à cocher. Les rétros ART se transforment en plaintes collectives. Les réunions de synchronisation inter-équipes (Scrum of Scrums) tournent à vide si le RTE n'y apporte pas de vraies décisions. Et le pire, SAFe crée un faux consensus. Tout le monde a participé au PI Planning, donc tout le monde pense avoir compris. Or, les équipes I et H n'ont pas du tout la même vision de la dépendance qui les unit. Et personne ne le découvrira qu'en fin de sprint.

LeSS et sa radicalité Scrum-pure. LeSS (Large-Scale Scrum) refuse le framework à couches. Un seul product backlog, une seule priorisation, pas de Product Manager qui double le PO, pas de couche d'architecture cadencée. À la place, un PO qui pilote vraiment, des équipes qui se parlent directement, une confiance dans l'émergence. C'est beau en théorie.

LeSS fonctionne quand les équipes sont matures, le PO vraiment impliqué, et le contexte organisationnel le permet (peu de sponsors divergents, peu de contraintes matérielles asynchrones). À Spotify, au début, ça a marché. Mais Spotify n'était pas une grosse structure. Spotify était une bande de gens très motivés qui voulaient que ça marche.

Dans un grand groupe industriel, avec des rapports hiérarchiques, des directions produit qui se font la guerre, des contraintes réglementaires, LeSS devient un acte de foi. Vous dites aux équipes "travaillez directement ensemble", mais les directeurs ne vous écoutent pas, et vous n'avez toujours pas de synchronisation. Vous gagnez de l'agilité locale, vous perdez de l'alignement global.

Les autres voies, OKR couplés à Scrum, modèles maison. Beaucoup d'organisations tentent une voie médiane, garder Scrum fort au niveau équipe, ajouter un layer léger de synchronisation (standup inter-équipes quotidien, roadmap trimestrielle, synchronisation des dépendances en pull plutôt qu'en push), ajouter des OKR pour forcer l'alignement stratégique. C'est moins codifié que SAFe, plus équilibré que LeSS dans certains contextes.

Le hic, c'est facile à rater. Vous perdez la discipline cadencée de SAFe et la confiance radicale de LeSS. Vous restez dans un entre-deux sans identité. Cela marche si vous avez un RTE qui sait vraiment ce qu'il fait, un PO mature, et des équipes qui accueillent la structure plutôt que de la subir.

Ma position, tranchée. Il n'existe pas de meilleur framework en absolu. Il existe un framework qui correspond à votre culture, votre maturité, votre contexte organisationnel, et à votre capacité à le piloter vraiment. Si vous êtes une grosse structure, peu mature en agile, avec des sponsors divergents, SAFe limite les dégâts. Si vous avez confiance et maturité, LeSS ou une voie médiane. Si vous doutez, SAFe. Mais arrêtez de croire que le framework réglera vos problèmes. Un mauvais RTE en SAFe, c'est pire qu'une absence de framework. Une belle équipe sans framework, c'est un gaspillage de potentiel.

Le rôle qui change tout, le Release Train Engineer

Vous pouvez avoir le framework le plus beau du monde. Si votre RTE est un coursier qui court entre les équipes et répète ce qu'on lui dit, vous êtes mort dans l'eau.

Le vrai RTE fait deux choses que personne d'autre ne fait. D'abord, il voit les dépendances avant qu'elles éclatent. Il a lu tous les backlogs. Il parle à tous les tech leads. Il sait que l'équipe A va bloquer sur une librairie fournie par l'équipe B au jour 25 du sprint, alors qu'elle croyait l'avoir au jour 10. Il remonte ça au PM avant le sprint, ou il rejamme les équipes dès le jour 22 pour parer au coup. Un RTE coursier, lui, apprend que la dépendance a échoué quand l'équipe le crie en standup.

Ensuite, il arbitre les arbitrages. Quand deux équipes se battent pour une ressource, quand une décision architecture va à l'encontre d'une décision produit, quand un sponsor veut ajouter deux semaines de périmètre à trois jours du PI Planning, le RTE ne remonte pas la question plus haut. Il l'arbitre. Il dit "voici le critère sur lequel je tranche". Cet arbitrage s'inscrit dans la stratégie globale du train, pas dans les intérêts locaux. Un RTE coursier demande l'avis de tout le monde et ralentit tout.

Sur ce train, j'ai vu la différence. Nous avions un premier RTE qui connaissait le framework sur le bout des doigts. Parfait en animation de réunion. Et complètement passif en décision. Nous avons changé. Le nouveau RTE était moins à l'aise sur les rituels, moins loquace, plus avisé sur le terrain. En deux PI, la vélocité a grimpé, les escalades ont baissé, les promesses on les tenait.

C'est pour ça que j'ai écrit (et donné gratuitement) un PDF sur les 12 anti-patterns SAFe. Le numéro un, le RTE coursier, tue plus de trains que tout le reste. Si vous lancez un train, cherchez quelqu'un qui sait dire non aux sponsors, qui lit les backlogs, qui prend des décisions et en assume les conséquences.

Cinq décisions structurantes au lancement d'un train

Le jour du kick-off d'un train, vous avez trois jours pour prendre cinq décisions. Pas des débats, des décisions. Elles vont vous conditionner les dix-huit mois qui suivent.

Un, le périmètre du train, tranchant et stable. Vous définissez qui dans, qui dehors. Quatre équipes ou sept ? Scope produit ou scope technique ? Une règle, le périmètre doit rester stable au moins trois ou quatre PI. Si vous le changez tous les deux PI, vous ne convergez vers rien. RTE, vous devez dire au sponsor : "Voilà le périmètre. Vous avez trois semaines pour négocier. Après, c'est gelé pour quatre PI." Non, ça ne plaît pas au sponsor. Oui, c'est non négociable.

Deux, le sponsor engagé, pas absent. Sponsor n'est pas un titre. C'est une présence. Cela signifie disponible une journée par mois, pas en simulation. Participant au PI Planning, vraiment. Qui écoute les équipes et répond aux questions, pas qui approuve a posteriori. J'ai vu des trains sans sponsor réel. Ils errent. J'ai vu un train où le sponsor était un directeur métier réel, qui se calait sur l'agenda du train, qui venait au planning, qui tranchait les priorités avec nuance. Ce train a volé.

Trois, la cadence du PI, alignée sur vos chaînes critiques. Deux semaines de sprint, trois sprints par PI, donc six semaines d'Increment Program. Quatre semaines d'Increment, six sprints. Cela vous donne un horizon de révision toutes les six ou douze semaines. Trop court, vous replanifiez à la semaine. Trop long, vous dérivez. Il existe une cadence juste pour votre contexte. Sur le contexte que je viens de décrire, nous avons décidé un PI de six semaines, trois sprints de deux semaines, puis une semaine à cheval pour synchroniser et rétroplanner. C'était parfait pour notre contexte de pièces détachées et de chaînes d'approvisionnement. Votre contexte n'est pas le nôtre. Mais décidez, ne vagabondez pas.

Quatre, la gouvernance des dépendances. Comment les équipes résolvent leurs dépendances ? Qui décide si on la retarde, on la contourne, on la change d'équipe ? Vous créez un forum des tech leads ? Vous donnez au RTE carte blanche ? Vous décidez que les équipes sortent une API stable au jour 5 du sprint, non négociable ? Décidez. Une gouvernance claire vaut mieux qu'une belle gouvernance qui change tous les trois semaines.

Cinq, la mesure du succès d'un train. Pas juste "vélocité stable". Vélocité stable sur quoi ? C'est quoi une user story pour vous ? Combien prend une story de taille 3 en jours ? Vous mesurez la stabilité de la prédiction ? Les escalades ? Le turnover ? La satisfaction client ou les anomalies en production ? Décidez ce qui compte pour vous, et mesurez-le franchement. Un train qui améliore sa vélocité mais laisse 40 % de bugs en prod, vous l'avez perdu.

Ces cinq décisions, vous les prenez en trois jours. Vous les revisitez au pire à chaque changement de sponsor ou de RTE. Vous les respectez.

Les signaux faibles qui vous disent que le train va dérailler

Il existe des signes précoces. Les bonnes équipes les voient au jour 20 du PI, pas au jour 35.

Premier signal, la vélocité prédite s'écroule. Vous aviez prédit 150 points pour le PI. À jour 15, vous avez livré 23 points et vous avez déjà creusé le double en dépendances cachées. Ce n'est pas une question de performance des équipes. C'est que le planning n'était pas réaliste. Ou que les dépendances ont explosé. À ce stade, vous avez une semaine pour rejammer et sauver le PI. Deux semaines, il est mort.

Deuxième signal, les escalades quotidiennes. Vous êtes au jour 10. Il y a trois escalades en cours. Jour 15, cinq escalades. Le RTE court après les problèmes, pas devant. C'est le signe que les dépendances n'ont pas été levées au planning, ou que l'arbitrage n'est pas fait. C'est grave.

Troisième signal, les rétros se transforment en plaintes. "On n'a pas le support du back-office", "les API sont instables", "c'est pas notre faute si le sponsor change d'avis". Une bonne rétro identifie ce qu'on peut contrôler et ce qu'on ne peut pas. Une rétro morte, c'est une liste de culpabilités externes. Ça signifie que le train n'a pas de RTE vraiment engagé, ou que le sponsor s'est volatilisé.

Quatrième signal, le sponsor disparaît. Il n'était déjà pas très là. Maintenant, le PM doit descendre deux niveaux hiérarchiques pour trouver qui décide vraiment. Préparez-vous à l'implosion en trois PI.

Cinquième signal, les tech leads sont en burnout. Ce ne sont pas les développeurs qui brûlent, c'est les leads. Ça signifie qu'on leur demande de jouer trop de rôles, arbitrage des dépendances, support des équipes, écriture de la stratégie architecture. Le système est surchargé. Allez lire les escalades de charge, réduisez le scope, ou ajoutez un lead. Mais c'est un signal rouge.

Ces cinq signaux, vous les observez sans même avoir besoin de data compliquées. Ils suffisent à vous dire que vous avez deux semaines à quatre semaines pour relancer, ou que le train est mort.

En conclusion

L'agilité à l'échelle n'est pas une doctrine. C'est une discipline. Et les gens qui la maîtrisent, ce ne sont jamais ceux qui ont lu tous les livres SAFe ou qui ont collectionné les certifications. Ce sont ceux qui ont lancé des trains, qui les ont vus échouer, qui ont dégagé les patterns, et qui savent comment bouger les leviers. Vous, vous travaillez en contexte, avec des gens réels, des sponsors impatients, des architectures complexes.

Voilà pourquoi je fais ce que je fais, accompagner les équipes qui embarquent là-dedans, et les aider à éviter les écueils que j'ai vus passer trente fois. SAFe, oui, si c'est bon pour vous. LeSS, oui, si vous avez confiance. Une voie médiane maison, oui. Mais pas comme un framework que vous achetez clés en main. Comme une structure que vous pilotez.

Si vous lancez un train, cherchez le bon RTE. Engagez vraiment le sponsor. Décidez les cinq points au jour un. Mesurez franchement. Vous avez 70 % de chances de succès.

Pour explorer cela plus loin, je vous propose deux parcours, une formation SAFe POPM si vous avez besoin du langage partagé au sein d'une grosse organisation, ou une intervention de diagnostic sur deux à cinq jours si vous êtes dans un premier train qui s'essouffle.

Pour aller plus loin

Cinq articles connexes à publier, placeholders à brancher en MDX :

Dépendances inter-équipes, les voir avant qu'elles ne vous tuent.
PI Planning, comment cadrer une synchronisation sans l'étouffer.
RTE coursier vs RTE stratège, le rôle qui change tout.
Sponsor absent, train perdu, ce qu'un vrai sponsor doit faire.
Les 12 anti-patterns SAFe que j'ai vus le plus souvent (lien vers le PDF lead magnet).