Depuis son apparition en 1993, Scrum s’est imposé comme l’un des cadres de travail les plus populaires pour gérer des projets complexes, promettant de livrer de la valeur rapidement, de manière itérative et incrémentale, tout en favorisant l’apprentissage continu et la transparence.
Mais quand il s’agit d’appliquer les principes de Scrum à des organisations entières composées de dizaines, voire de centaines d’équipes, comment conserver les bénéfices de Scrum à grande échelle sans retomber dans les travers du contrôle hiérarchique et de la bureaucratie ?
Jeff Sutherland, co créateur de Scrum, tente de répondre à cette question en proposant Scrum@Scale.
Une méta-structure composée d’un ensemble de principes et de rôles permettant à une organisation de croître de manière organique autour des fondations de Scrum, tout en préservant son agilité, sa rapidité et sa capacité d’adaptation.
Présentation générale du framework Scrum@Scale
Dans cette présentation du framework, nous aborderons son origine, sa stratégie de passage à l’échelle, les objectifs clefs qu’il cherche à atteindre, et la manière dont il est structuré.
1) L'origine du framework
Scrum@Scale a été développé par Jeff Sutherland dans les années 2010 après avoir observé les limites des premières adaptations de Scrum à grande échelle, et mesuré les principaux défis auxquels sont confrontées les grandes organisations :
- Définir des priorités de manière efficace avec des ressources limitées,
- Livrer un logiciel fonctionnel de haute qualité en respectant les délais,
- S’adapter au changement, tant du point de vue organisationnel que du produit.
2) Un système vivant à l’échelle
Plutôt que d’ajouter des couches de gouvernance, comme le proposent d’autres frameworks, Scrum@Scale vise à mettre à l’échelle l’organisation comme un système vivant.
Chaque équipe Scrum doit rester autonome, tout en étant connectée à l’ensemble via des boucles de communication simples et cohérentes.
L’objectif est d’éviter d’introduire davantage de complexité lors de la création d’équipes supplémentaires.
Le cœur du modèle repose sur un principe fondamental : viser une bureaucratie minimum viable pour accélérer les prises de décisions et leurs mises en œuvre.
Cette philosophie d’approche est également très présente dans le framework LeSS.
3) Les objectifs clefs
Scrum@Scale vise 4 objectifs :
- Maximiser la vélocité organisationnelle,
- Favoriser une vision partagée et un alignement clair sur la valeur,
- Réduire les gaspillages de coordination,
- Créer une organisation adaptable, capable de réagir rapidement aux changements du marché.
Les événements fondamentaux de Scrum sont conservés et étendus à plusieurs niveaux de l’organisation.
Chaque évènement maximise la transparence, favorise la synchronisation inter-équipes et réduit les délais de livraison.
4) La structure
La structure générale de Scrum@Scale s’articule autour de deux cycles imbriqués :
- Le cycle de livraison (Scrum Master Cycle), axé sur la productivité et la qualité des équipes, autrement dit le « comment »,
- Le cycle de pilotage de la valeur (Product Owner Cycle), centré sur l’orientation stratégique et la priorisation, autrement dit le « quoi ».
Ces deux cycles se rejoignent sur des valeurs communes : transparence, communication et amélioration continue.
Dans la suite de l’article, nous aborderons les principes du framework Scrum@Scale pour bien appréhender sa philosophie d’approche, et mieux comprendre les pratiques sous-jacentes.
Ensuite, nous verrons dans quel contexte Scrum@Scale peut être pertinent et dans quels cas il ne l’est pas.
Enfin, nous insisterons sur les 9 éléments clefs importants à maîtriser pour garantir le succès de la mise en place de Scrum@Scale.
Principes du framework Scrum@Scale
Voici un tour d’horizon des principes les plus importants du framework Scrum@Scale.
1) L’évolutivité organique
Scrum@Scale ne propose pas une structure organisationnelle prédéfinie.
Il s’adapte de manière fractale : chaque équipe Scrum fonctionne selon les mêmes règles que l’ensemble de l’organisation.
Autrement dit, ce qui fonctionne à petite échelle doit aussi fonctionner à grande échelle, sans ajout de complexité inutile.
2) L’auto-organisation
Les équipes Scrum restent autonomes dans la manière dont elles atteignent leurs objectifs.
Scrum@Scale permet à ces équipes de s’organiser entre elles via des points de coordination, tels que le Scrum of Scrums (SoS), sans dépendre d’un management centralisé.
3) La transparence et l’empirisme
Les décisions se basent sur l’observation de faits mesurables : vélocité, valeur livrée, obstacles, satisfaction client.
Les boucles de feedback fréquentes assurent que l’organisation apprend en continu, à tous les niveaux.
4) L’alignement stratégique
Le Product Owner Cycle garantit que chaque équipe travaille vers un objectif commun, décliné à travers des objectifs de produit, puis des objectifs de sprint alignés.
Cette cascade d’objectifs assure la cohérence de la valeur délivrée à l’échelle de l’entreprise.
Dans quels contextes utiliser Scrum@Scale ?
Voici quelques situations où le Scrum@Scale peut être utilisé :
1) Quand le besoin de coordination devient un frein
Scrum@Scale s’adresse aux organisations où :
- Plusieurs équipes Scrum travaillent sur un même produit,
- Les dépendances ralentissent la livraison,
- La prise de décision devient trop souvent centralisée.
Exemples typiques :
- Grandes entreprises IT ou industrielles,
- Programmes de transformation digitale,
- Produits complexes intégrant matériel et logiciel.
2) Quand l’entreprise veut passer à l’échelle sans lourdeur
Contrairement à d’autres cadres d’agilité à l’échelle comme SAFe, Scrum@Scale se distingue par sa légèreté.
Il est idéal pour des organisations cherchant à croître sans imposer de hiérarchie rigide ou de rôles supplémentaires.
3) Quand la culture agile est déjà bien ancrée
Scrum@Scale ne fonctionne bien que si :
- Les équipes Scrum sont matures et autonomes pour délivrer de la valeur,
- Le niveau de dépendances entre les équipes reste faible,
- La direction est impliquée dans la transformation,
- La culture de la transparence et de l’amélioration continue est vivante.
Autrement dit, Scrum@Scale est un cadre de travail pour des entreprises déjà agiles ou en voie de le devenir sérieusement.
9 éléments clefs pour maîtriser le framework Scrum@Scale
Voici les 9 éléments importants pour mettre en place le framework Scrum@Scale efficacement.
1) Un Scrum of Scrums (SoS) pour mettre Scrum à l’échelle
Scrum conseille de limiter la composition d’une équipe Scrum à 10 personnes.
Chaque équipe, composée d’un Scrum Master (SM), d’un Product Owner (PO) et de développeurs, vise 4 objectifs :
- Maximiser le flux de travail pour délivrer de la valeur,
- Augmenter la performance au fil du temps,
- Travailler d’une manière durable et profitable à tous,
- Accélérer la boucle de feedbacks avec les clients
Un Scrum of Scrums (SoS) est un ensemble d’équipes agiles qui opère comme une équipe agile. Scrum@Scale considère que la taille optimale pour un SoS est de l’ordre de 4 à 5 équipes.
Un SoS est responsable de livrer des incréments intégrés à chaque fin de sprint.
Idéalement, il dispose de toutes les compétences nécessaires pour délivrer de la valeur directement aux utilisateurs.
Le cadencement (itérations de même durée pour toutes les équipes) et la synchronisation (itérations qui démarrent au même moment pour toutes les équipes) sont des principes structurants sur lesquels reposent tous les frameworks d’agilité à l’échelle du marché.
Ils permettent à chaque fin d’itération :
- Une intégration au plus tôt du travail fourni par l’ensemble des équipes
- Une démonstration d’un produit unique et commun
Selon la taille des organisations, plusieurs SoS peuvent être nécessaires pour délivrer un produit complexe.
Dans ce cas, un « Scrum of Scrums of Scrums » (SoSoS) peut être créé.
2) Un Scaled Daily Scrum (SDS) pour coordonner les équipes
Le Scaled Daily Scrum (SDS) est la mise à l’échelle du Daily Scrum pratiqué dans les équipes Scrum.
Il permet de coordonner plusieurs équipes Scrum et de mesurer la progression des équipes au regard d’un objectif commun de sprint.
Il réduit le temps de coordination et offre une visibilité globale sur la progression multi-équipes.
Chaque équipe y délègue un représentant (souvent le Scrum Master ou un référent technique) pour :
- synchroniser les livraisons,
- identifier les dépendances,
- anticiper les risques
- et lever les obstacles transverses.
Le SDS est animé de manière hebdomadaire par un Scrum of Scrums Master (SoSM). Il peut être un des Scrum Master, soit une personne dédiée à ce rôle.
Leader au service des équipes Scrum et de l’organisation, il est responsable des efforts communs et garant de l’efficacité du dispositif.
Il a les mêmes responsabilités qu’un Scrum Master, mais à l’échelle. Il s’assure que les évènements à l’échelle ont bien lieu.
Voici quelques exemples de questions que le SoSM peut poser aux Scrum Master lors du SDS :
- Quels obstacles empêchent votre équipe de progresser vers l’objectif de sprint ?
- Est-ce qu’une équipe est bloquée par une autre équipe ?
- Avez-vous découvert des nouvelles dépendances ?
Pour mieux suivre les dépendances et les éventuels blocages, nous vous conseillons d’utiliser le tableau des dépendances construit lors du Scaled Sprint Planning :
Clef de lecture :
Les User Story (couleur bleue), nécessitent des travaux (couleur rouge) réalisés par les autres équipes.
Les fils rouges symbolisent des dépendances.
Les dépendances à l’intérieur d’un même sprint sont à éviter, autant que possible, afin de limiter les impacts liés à d’éventuels retards.
3) Un MetaScrum Meeting (MSM) pour aligner les équipes sur des priorités claires
Le MetaScrum (MS) est le miroir du SoS, mais côté business.
Il réunit les Product Owners d’un ensemble d’équipes pour définir une vision commune, s’aligner sur les priorités produit et construire l’unique backlog multi-équipes.
Un MetaScrum Meeting (MSM) est animé de manière hebdomadaire par un Chief Product Owner (CPO).
Il peut être un des Product Owner, soit une personne dédiée à ce rôle.
Unique représentant fonctionnel de l’ensemble des équipes qui composent le SoS, le CPO :
- définit la vision stratégique et le release planning pour le produit entier,
- crée un unique backlog priorisé,
- définit et évalue la valeur délivrée,
- récolte les feedbacks des clients,
- et ajuste les priorités du backlog.
Le contenu du meeting est la synchronisation des backlogs, l’identification des interdépendances produit et l’ajustement des priorités selon la valeur business.
Le MSM optimise la cohérence de la roadmap et prévient les duplications ou conflits d’objectifs.
Il permet de prioriser collectivement ce qui a le plus d’impact sur la stratégie d’entreprise.
4) Une Scaled Sprint Review pour valoriser le travail collectif et capter des feedbacks
La Scaled Sprint Review a pour objectif de démontrer à chaque fin de sprint la valeur globale, fruit de l’intégration des incréments des équipes.
Les participants sont les équipes Scrums, les parties prenantes, les clients internes ou externes.
La Scaled Sprint Review est importante, car elle est une boucle de feedbacks directe entre les équipes et les utilisateurs.
Lorsque chaque équipe présente tour à tour le fruit de son travail, la démonstration est souvent décousue.
Privilégiez plutôt une présentation des nouvelles fonctionnalités du produit par le CPO, pour asseoir sa légitimité et montrer qu’il maîtrise le produit dans son intégralité.
Cet événement est aussi l’occasion de montrer que le collectif est soudé, comme s’il s’agissait d’une review d’équipe Scrum.
5) Une Scaled Retrospective pour s’améliorer collectivement
L’objectif de la Scaled Retrospective est de revenir sur les améliorations effectuées pendant le précédent sprint, et d’identifier les prochaines améliorations collectives à l’échelle du système selon différents prismes (organisation, processus, communication).
Elle complète les rétrospectives d’équipes.
Elle a lieu à chaque fin de sprint.
Les participants sont le SoSM, en tant que garant de l'événement et animateur, et les Scrum Masters des équipes.
Nous vous conseillons de vous nourrir des rétrospectives des équipes pour capter les irritants en avance de phase.
Les freins les plus pénalisants pour les équipes doivent faire l’objet d’ateliers de résolution de problèmes.
Selon la taille de votre SoS, vous pouvez mener plusieurs ateliers en parallèle en déléguant l’animation à quelques Scrum Master volontaires.
6) Un Product Backlog Refinement global pour un affinage collectif
Le Product Backlog Refinement global consiste à affiner les items du backlog avec plusieurs équipes.
Il vise à anticiper les dépendances et à aligner les roadmaps des différentes équipes.
Les participants sont les Product Owners, le CPO, les experts métier et techniques.
Pour lancer la dynamique, nous conseillons au SoSM d’animer les premières séances en utilisant un kanban de maturation.
Les séances de Product Backlog Refinement permettent au CPO de présenter les User Story aux Product Owner.
Si celles-ci sont suffisamment claires, elles sont ensuite affinées et estimées dans les différentes équipes.
Sinon, elles sont complétées par le CPO qui les présentera à nouveau lors de la prochaine séance.
7) Un Scaled Sprint Planning (SSM) pour planifier collectivement
Un Scaled Sprint Planning (SSM) est animé par le CPO à chaque début de sprint.
Les participants sont le CPO, le SoSM, les Scrum Master et les Product Owner.
Le but de l'événement est de définir collectivement :
- un objectif commun de sprint,
- une répartition des US les plus prioritaires du Product Backlog dans les différentes équipes,
- un tableau des dépendances entre équipes,
- une mise à jour de la roadmap globale et sa déclinaison pour chacune des équipes.
Lors de la séance, le CPO et les Product Owner apportent des éléments sur ce qui doit être délivré dans le sprint qui démarre, tandis que le SoSM et les Scrum Masters apportent des éléments sur la capacité à faire et les prérequis techniques.
Même si l’attention est portée sur le sprint en cours, il est nécessaire de donner de la visibilité à chacune des équipes sur les travaux à venir dans les futurs sprints, notamment pour mieux gérer les dépendances.
Les mécanismes de planification du framework SAFe peuvent constituer une source d’inspiration complémentaire pour planifier des travaux à grande échelle.
8) Un Executive Action Team (EAT) pour transformer l’organisation
L’EAT (Executive Action Team) est une équipe qui joue un rôle de Scrum Master pour une organisation agile.
Garante du cadre Scrum au niveau de l’organisation, elle est responsable de soutenir la transformation agile et de lever les obstacles systémiques qui ne peuvent pas être levés par les membres des SoS.
Elle coordonne également les SoS et joue un rôle d’interface avec les parties non agiles de l’organisation.
L’EAT Review, souvent mensuelle, garantit la cohérence et la pérennité de l’agilité à l’échelle dans l’entreprise.
Les participants sont les membres de l’EAT (dirigeants de l’entreprise, leaders agiles, coachs, managers).
Dans nos transformations agiles, un manque d’implication de la direction dans les centres agiles est souvent observé. L’EAT a donc le mérite de pallier ce manque.
L’EAT définit la roadmap de transformation agile d’entreprise et possède un backlog qui contient l’ensemble des éléments qui soutiennent la transformation.
9) Un Executive MetaScrum (EMS) pour connecter la stratégie à l’exécution
L’Executive MetaScrum (EMS) joue le rôle de Product Owner pour l’organisation agile toute entière.
Il regroupe les décideurs clés (direction générale, sponsors, CPOs, directions produit, marketing, finance, et autres fonctions stratégiques) pour aligner la stratégie de l’entreprise sur les objectifs produits.
Lors d’un EMS Event mensuel, les CPOs rencontrent les dirigeants et les parties prenantes pour :
- mettre à jour la vision stratégique,
- négocier les priorités à long terme,
- revoir les budgets,
- et réaligner les équipes pour maximiser la valeur produite.
La stratégie d’entreprise est formulée grâce à des OKR (Objectives & Key Results) qui favorisent l’alignement et la transparence en étant focus sur les résultats.
Chaque objectif est décliné en résultats clefs et chaque résultat est structuré de la manière suivante :
- une date de début avec un résultat associé (« from »),
- une date de fin avec un résultat attendu (« to »).
Enseignements clés du modèle
L’une des forces majeures de Scrum@Scale est la synchronisation naturelle entre les 2 boucles :
- Les revues et les rétrospectives du Scrum Master Cycle nourrissent le MetaScrum et l’EMS
- Les décisions de priorisations issues du Product Owner Cycle influencent les plans de livraison du Scrum Master Cycle
Cette interconnexion crée un flux d’information bidirectionnel :
- Du terrain vers la stratégie (feedbacks, obstacles, risques)
- De la stratégie vers le terrain (vision, priorités, objectifs)
Voici un récapitulatif des évènements du framework Scrum@Scale :
Conclusion
Scrum@Scale propose une approche organique, systémique et légère de l’agilité à l’échelle.
Plutôt que d’ajouter de la structure, il cherche à étendre la simplicité de Scrum à tous les niveaux de l’organisation.
En reliant les cycles de pilotage (Product Owners) et d’exécution (Scrum Masters) via des boucles de feedbacks claires, il permet de créer une organisation vivante, capable de s’aligner sur la stratégie, livrer rapidement de la valeur, et apprendre collectivement.
Scrum@Scale n’est pas une recette miracle. C'est plutôt un cadre adaptable qui doit être mis en œuvre avec rigueur, conviction et accompagnement.
Bien maîtrisé, il devient un puissant levier de transformation agile, capable de concilier autonomie, alignement et impact à grande échelle.
