Nexus vs LeSS : Deux cadres agiles pour mettre Scrum à l'échelle sans lourdeur

Nexus vs LeSS : Deux cadres agiles pour mettre Scrum à l’échelle sans lourdeur

Cet article fait partie de notre Le Guide Ultime de Scrum : Maîtriser le Framework Agile de A à Z.

Lorsque votre organisation grandit et qu’un seul collectif ne suffit plus pour faire évoluer un produit complexe, la question du passage à l’échelle devient inévitable. Dans nos précédents articles, nous avons exploré des mécanismes informels comme le Scrum of Scrums, ainsi que des cadres très structurés comme SAFe. Cependant, entre la simplicité d’une coordination de proximité et la lourdeur d’une architecture d’entreprise complète, il existe une voie médiane exigeante et fidèle aux racines de l’agilité : les frameworks agiles d’agilité à l’échelle minimalistes. Deux cadres majeurs incarnent cette philosophie : Nexus, conçu par le co-créateur de Scrum Ken Schwaber via Scrum.org, et Large-Scale Scrum (LeSS), formalisé par Craig Larman et Bas Vodde. Comment ces frameworks permettent-ils de faire collaborer de multiples équipes sans dénaturer Scrum ? Quels sont leurs apports respectifs, comment se situent-ils par rapport à SAFe et quel cadre adopter selon votre contexte organisationnel ? Découvrons-le en détail.

Nexus : L’exosquelette Scrum selon Scrum.org

Créé par Ken Schwaber (co-créateur du Scrum Guide aux côtés de Jeff Sutherland) et publié par Scrum.org, le framework Nexus est souvent décrit par son auteur comme « l’exosquelette de Scrum ». Il a été spécialement conçu pour orchestrer le travail de 3 à 9 équipes Scrum travaillant de concert sur un unique Product Backlog pour délivrer un seul Incrément de produit intégré à chaque Sprint.

Nexus ne modifie pas les règles fondamentales du Scrum Guide ; il vient ajouter une couche minimale dédiée à un problème clé du passage à l’échelle : la détection et la résolution des dépendances cross-équipes ainsi que l’assurance d’une intégration continue efficace.

Les éléments constitutifs du framework Nexus

  • Un rôle dédié – L’Équipe d’Intégration Nexus (Nexus Integration Team – NIT) : Cette équipe est garante de la livraison d’un Incrément intégré à chaque fin de Sprint. Elle se compose du Product Owner unique du produit, d’un Scrum Master et de membres d’intégration (qui sont fréquemment aussi membres des équipes Scrum du Nexus). La NIT n’est pas une équipe de supervision managériale, mais un collectif de facilitation technique et fonctionnelle chargé d’aider les équipes à surmonter les blocages d’intégration.
  • Un artefact dédié – Le Nexus Sprint Backlog : Il s’agit de la vue consolidée de l’ensemble des éléments du Product Backlog sélectionnés par les différentes équipes pour le Sprint en cours. Il permet de matérialiser visuellement les dépendances techniques et fonctionnelles entre équipes.
  • Exemple de tableau Nexus Sprint Backlog montrant la gestion des dépendances entre équipes Scrum
    Le Nexus Sprint Backlog permet de matérialiser et d’anticiper visuellement les dépendances entre équipes. (Rob Maher, Patricia Kong (CC BY-SA 4.0), via Wikimedia Commons.)
  • Des événements ajustés :
    • Nexus Sprint Planning : Les représentants des équipes se réunissent pour analyser le Product Backlog, identifier les dépendances croisées et ajuster la répartition du travail avant que chaque équipe ne conduise son propre Sprint Planning.
    • Nexus Daily Scrum : Réunion quotidienne brève où des représentants de chaque équipe partagent les problèmes d’intégration détectés, ajustent le Nexus Sprint Backlog et anticipent les blocages avant la tenue du Daily Scrum propre à chaque équipe.
    • Nexus Sprint Review : Une seule revue globale est organisée à la fin du Sprint avec les parties prenantes pour faire la démonstration de l’Incrément totalement intégré (et non des démos isolées par équipe).
    • Nexus Sprint Retrospective : Elle encadre la rétrospective de chaque équipe. Des représentants identifient d’abord les problèmes systémiques globaux, puis les équipes mènent leurs rétrospectives individuelles, et enfin une synthèse commune est effectuée pour convenir d’actions d’amélioration à l’échelle du Nexus.

Large-Scale Scrum (LeSS) : Dés-incrémenter la structure pour simplifier l’organisation

Imaginé par Craig Larman et Bas Vodde à partir d’expérimentations menées dans de grands projets télécoms et bancaires, Large-Scale Scrum (LeSS) repose sur un constat fort : ajouter des règles, des processus et des couches hiérarchiques pour passer à l’échelle détruit l’agilité. La promesse de LeSS tient dans son slogan : « More with LeSS » (Obtenir plus de valeur avec moins de structures imposées).

Contrairement aux modèles qui ajoutent des rou rouages managériaux, LeSS propose une démarche de « dés-incrémentation » organisationnelle. Il s’agit de restructurer l’entreprise pour qu’elle puisse appliquer le cadre Scrum standard à grande échelle, en s’appuyant sur les principes de la pensée systémique et de la culture Lean.

1. LeSS de base (jusqu’à 8 équipes)

Pour un groupe composé de 2 à environ 8 équipes (soit jusqu’à une soixantaine de personnes), LeSS conserve la structure stricte de Scrum :

  • Un seul Product Backlog : Toutes les équipes piochent leurs éléments dans la même liste priorisée.
  • Un seul Product Owner : Il détient la vision produit et l’arbitrage global des priorités.
  • Une seule Definition of Done (DoD) commune : Complétée éventuellement par chaque équipe si elle souhaite durcir ses propres exigences qualitatives.
  • Schéma synthétique du cycle et des événements du framework Scrum en français

    Le fonctionnement de base de Scrum reste le socle de chaque équipe dans un modèle LeSS. (Mdaumas (CC BY-SA 3.0), via Wikimedia Commons.)

  • Des équipes Feature Cross-Fonctionnelles : Chaque équipe est capable d’implémenter une fonctionnalité de bout en bout (du composant frontend au composant backend), éliminant ainsi les équipes par composant technique.
  • Des cérémonies partagées : La planification est divisée en deux temps (Sprint Planning 1 commun pour répartir les items, Sprint Planning 2 propre aux équipes). La revue et la rétrospective globale réunissent l’ensemble du collectif.

2. LeSS Huge (au-delà de 8 équipes)

Lorsque le développement réunit plusieurs centaines de personnes sur un même produit complexe, un seul Product Owner ne peut physiquement plus traiter l’ensemble des besoins. LeSS propose alors sa déclinaison LeSS Huge.

LeSS Huge introduit le concept de Requirements Areas (Domaines d’exigences). Le Product Backlog principal est découpé en plusieurs Area Product Backlogs. Un Area Product Owner (APO) est nommé pour chaque domaine d’exigences. Chaque domaine regroupe entre 4 et 8 équipes et fonctionne comme une structure LeSS classique. Le Product Owner global conserve l’alignement stratégique global entre les différents domaines.

Comparatif détaillé : Nexus vs LeSS vs SAFe

Pour faire le bon choix stratégique, il est essentiel de comparer Nexus et LeSS avec SAFe (Scaled Agile Framework), le cadre le plus déployé en grande entreprise.

Tableau de synthèse comparative

<

ul>

  • Niveau de structure ajoutée :
    • Nexus : Très léger (ajoute 1 équipe d’intégration, 1 artefact et ajuste les événements existants).
    • LeSS : Minimaliste au niveau du cadre, mais exigeant une refonte structurelle profonde de l’entreprise (suppression des silos et du management intermédiaire).
    • SAFe : Élevé (prescrit de nombreux rôles comme Release Train Engineer, Solution Architect, des événements comme le PI Planning, et des couches Portfolio/Solution).
  • Capacité de passage à l’échelle :
    • Nexus : Idéal pour 3 à 9 équipes (30 à 80 personnes) travaillant sur un produit unique.
    • Schéma d'organisation montrant la coordination entre plusieurs équipes Scrum
      Schéma conceptuel de la coordination multi-équipes agile à l’échelle. (Llunnaz (CC BY-SA 4.0), via Wikimedia Commons.)
    • LeSS : 2 à 8 équipes en LeSS de base ; de plusieurs centaines à milliers de personnes avec LeSS Huge.
    • SAFe : De 50 personnes à plusieurs milliers au niveau entreprise/portefeuille.
  • Philosophie et approche du changement :

    <

    ul>

  • Nexus : Approche empirique axée sur le développement logiciel, axée sur la résolution des dépendances techniques et l’intégration continue.
  • LeSS : Transformation de l’organisation (

    Photo : cottonbro studio sur Pexels.

    Pour aller plus loin

    Liens affiliés Amazon : en tant que Partenaire Amazon, ce site perçoit une commission sur les achats éligibles réalisés via ces liens, sans coût supplémentaire pour vous.

    The Nexus Framework for Scaling Scrum: Continuously Delivering an Integrated Product with Multiple Scrum Teams, Kurt Bittner, Patricia Kong, Dave West

    Écrit par les experts de Scrum.org, cet ouvrage offre une explication concrète du framework Nexus appuyée par un cas d’étude détaillé.

    Large-Scale Scrum: More with LeSS, Craig Larman, Bas Vodde

    Le livre de référence des créateurs de LeSS, indispensable pour comprendre la simplification structurelle et l’organisation en Feature Teams.

    Autres ressources sur l’agilité

    Sources

  • Publications similaires

    Laisser un commentaire