Quand plusieurs équipes Scrum travaillent sur un même produit, la coordination devient rapidement un problème structurel. Qui décide des priorités? Comment intégrer le travail de sept équipes dans un livrable cohérent à chaque sprint? C’est à cette question que répondent les frameworks de scaling agile, c’est-à-dire les cadres méthodologiques conçus pour étendre les pratiques agiles au-delà d’une seule équipe.
Quatre frameworks dominent le marché: SAFe, LeSS, Nexus et Scrum@Scale. Chacun propose une philosophie différente et convient à des contextes distincts.
Ce que le scaling agile cherche à résoudre
Une équipe Scrum de sept personnes fonctionne avec un Product Owner, un backlog et des cérémonies bien cadrées. Dès que trois, cinq ou douze équipes collaborent sur le même produit, plusieurs tensions apparaissent: les dépendances techniques ralentissent les livraisons, les priorités entrent en conflit et l’intégration du travail devient un chantier à part entière.
Le scaling agile ne consiste pas à multiplier les équipes, mais à concevoir une organisation capable de livrer de la valeur à grande échelle tout en préservant les principes de l’agilité: feedback rapide, adaptation continue et autonomie des équipes. C’est sur la manière d’atteindre cet équilibre que les quatre frameworks divergent.
SAFe: un cadre complet pour les grandes organisations
Le Scaled Agile Framework est le plus répandu. Selon le State of Agile Report 2023, 37% des praticiens agiles l’utilisent. SAFe organise les équipes en Agile Release Trains (ART), des regroupements de cinq à douze équipes qui planifient ensemble lors de cérémonies appelées PI Planning (Program Increment), sur des cycles de huit à douze semaines.
SAFe fournit un cadre prescriptif à plusieurs niveaux: équipe, programme, solution et portefeuille. Cette structure détaillée constitue à la fois sa force et sa limite. Pour une grande organisation qui migre depuis un modèle en cascade, SAFe offre une feuille de route complète avec des rôles, des cérémonies et des artefacts définis à chaque niveau. En revanche, ses détracteurs lui reprochent de reproduire les rigidités du waterfall sous une étiquette agile, avec une bureaucratie qui s’additionne à l’ancienne plutôt que de la remplacer.
LeSS: le minimalisme radical
Large-Scale Scrum, conçu par Craig Larman et Bas Vodde, part du principe inverse: ajouter le strict minimum au Scrum standard. Jusqu’à huit équipes partagent un seul Product Owner, un seul backlog et une même Definition of Done (critères d’acceptation communs). Pas de nouveaux rôles, pas de nouvelles cérémonies. LeSS Huge étend ce modèle au-delà de huit équipes en ajoutant des Area Product Owners par domaine fonctionnel.
Cette simplicité a toutefois un prix: LeSS exige une maturité agile solide de la part des équipes et un engagement profond de la direction, car il implique souvent une restructuration organisationnelle. Ce n’est pas un framework que l’on superpose à une organisation existante: il la transforme. Pour les organisations qui pratiquent Scrum depuis plusieurs années, LeSS est probablement le cadre le plus fidèle à l’esprit agile.
Nexus: un exosquelette léger pour un seul produit
Créé par Ken Schwaber, co-créateur de Scrum, Nexus se présente comme un “exosquelette” qui connecte trois à neuf équipes Scrum pour livrer un seul produit intégré. Son ajout principal est la Nexus Integration Team, responsable de la coordination technique et de l’intégration.
Les cérémonies Scrum existantes sont étendues plutôt que remplacées: Cross-Team Refinement, Nexus Sprint Planning, Nexus Sprint Review. Le Product Owner reste unique, le backlog aussi. Nexus ne touche ni à la structure organisationnelle ni au niveau portefeuille, ce qui en fait le cadre le moins intrusif. Cette portée limitée (environ quatre-vingts praticiens) convient aux organisations qui découvrent le scaling, à condition que le périmètre reste celui d’un seul produit.
Scrum@Scale: la modularité par le réseau
Jeff Sutherland, l’autre co-créateur de Scrum, a conçu Scrum@Scale comme un modèle modulaire. Les équipes se connectent en réseau via un Scrum of Scrums (SoS), une réunion régulière où un représentant de chaque équipe partage les avancées, les obstacles et les dépendances. Au niveau stratégique, un Executive Action Team (EAT) pilote la transformation organisationnelle et lève les blocages systémiques que les équipes ne peuvent pas résoudre seules.
Ce framework sépare explicitement deux responsabilités: le cycle Product Owner (quoi livrer) et le cycle Scrum Master (comment livrer), ce qui permet à chaque dimension de progresser à son propre rythme. Scrum@Scale est plus flexible que SAFe et moins exigeant que LeSS en matière de transformation, car il s’adapte progressivement à mesure que l’organisation grandit. Pour les entreprises qui souhaitent scaler sans tout remettre à plat, c’est une option pragmatique.
Comment orienter le choix?
Le choix d’un framework de scaling dépend avant tout du contexte organisationnel, et quatre critères permettent de structurer la réflexion. La maturité agile constitue le premier filtre: les frameworks légers comme LeSS et Nexus supposent des équipes déjà solides en Scrum, tandis que SAFe convient mieux aux organisations en transition depuis un modèle prédictif grâce à ses guides et garde-fous détaillés.
La taille et le niveau de contrôle souhaité déterminent ensuite le périmètre. Nexus couvre trois à neuf équipes, LeSS jusqu’à huit (LeSS Huge au-delà), SAFe s’adresse aux organisations de cinquante personnes et plus, et Scrum@Scale s’adapte à toute taille grâce à sa structure modulaire. Sur l’axe du contrôle, SAFe fournit un cadre prescriptif à chaque niveau hiérarchique, tandis que LeSS et Nexus laissent davantage d’autonomie aux équipes.
L’appétit au changement organisationnel reste enfin déterminant, car LeSS exige une restructuration profonde là où SAFe peut se superposer à l’existant, ce qui facilite l’adoption mais peut aussi perpétuer des dysfonctionnements, tandis que Nexus reste le moins intrusif des quatre.
En pratique, personne n’applique un framework à 100%
La réalité du terrain est plus nuancée que les présentations officielles. La plupart des organisations combinent des éléments de plusieurs frameworks selon leur secteur, leur historique et leur maturité. Un PI Planning emprunté à SAFe peut coexister avec un backlog unique inspiré de LeSS et une Nexus Integration Team pour gérer les dépendances techniques.
L’erreur la plus fréquente n’est d’ailleurs pas de choisir le mauvais framework, mais de chercher à scaler avant d’avoir des équipes Scrum réellement fonctionnelles. Aucun cadre de mise à l’échelle ne compensera des sprints mal maîtrisés, des Product Owners absents ou des équipes recomposées à chaque projet. Avant de choisir entre SAFe, LeSS, Nexus ou Scrum@Scale, la question la plus utile reste: nos équipes ont-elles vraiment besoin d’un framework de scaling, ou ont-elles d’abord besoin de mieux maîtriser Scrum?