L’équipe Scrum devrait se composer de jusqu’à dix personnes. Mais que faire lorsque un groupe plus large de spécialistes doit travailler sur un projet ? Ou si l’organisation décide de suivre une méthode de gestion agile ? Pour résoudre ce problème, les développeurs Scrum ont proposé Scrum@Scale. C’est une architecture sans échelle pour organiser des équipes entières selon les principes Scrum.
Élargir Scrum – table des matières :
Introduction
Dès qu’une organisation grandit, de nouveaux types de problèmes apparaissent. Par exemple, une baisse de l’efficacité des employés causée par une structure interne complexe, une prise de décision difficile ou un manque de direction. Les entreprises qui fonctionnent de manière agile au niveau des petites équipes de projet cherchent souvent à s’élargir.
De nombreuses entreprises se débrouillent bien sans élargir Scrum. Même si de nombreuses équipes Scrum fonctionnent simultanément, elles n’ont pas besoin de coordination car les groupes opèrent de manière indépendante. Cependant, cela ne signifie pas qu’il s’agit d’un Scrum multi-équipes. Le besoin d’élargir se fait sentir uniquement lorsque la plupart de l’organisation travaille sur un produit et peut synchroniser efficacement ses multiples équipes Scrum.
La plupart des organisations qui adoptent des méthodes de gestion agile à grande échelle choisissent le modèle SAFE, ou Scaled Agile Framework. Aujourd’hui, cependant, nous ne nous concentrerons pas sur SAFE mais nous discuterons d’un modèle différent appelé Scrum@Scale, car selon le 15ème rapport sur l’état de l’agilité de 2021, c’est le deuxième meilleur choix parmi les entreprises qui optent pour l’agilité.
Scrum@Scale
En 1996, les créateurs de Scrum, Jeff Sutherland et Ken Schwaber, travaillaient sur un grand projet. En le faisant, ils avaient du mal à garder les petites équipes travaillant en Scrum synchronisées. Ils ont trouvé un moyen de l’élargir, qu’ils ont finalement appelé Scrum@Scale.
Analogiquement au Guide Scrum officiel, il y avait le Guide Scrum@Scale, qui définit cette manière d’élargir le travail comme :
Un cadre dans lequel des réseaux d’équipes Scrum opèrent en suivant le Guide Scrum pour résoudre des problèmes adaptatifs complexes et livrer créativement des produits avec autant de valeur que possible.
La prémisse de base de Scrum@Scale est la simplicité et l’efficacité. Par conséquent, son fonctionnement est basé sur une architecture sans échelle. En d’autres termes, il utilise Scrum pour élargir Scrum. De cette manière, une équipe Scrum composée d’individus agissant en tant que Product Owner, Scrum Master ou Développeur devient le Scrum des Scrums : une équipe composée d’équipes.
Le Scrum des Scrums
Le Scrum des Scrums est une équipe Scrum avec des personnes occupant des rôles Scrum traditionnels. Cependant, puisque la tâche du Scrum des Scrums est d’intégrer les résultats du travail de plusieurs équipes Scrum, elle a besoin de postes supplémentaires :
- Équipe Product Owner – un groupe de Product Owners qui se réunissent pour convenir des priorités et créer une vision produit cohérente
- Chief Product Owner – le Product Owner de l’équipe Scrum ou une personne qui s’occupe exclusivement du Scrum des Scrums
- Scrum des Scrums Master – la personne qui supervise l’efficacité du Scrum des Scrums.
Ils se rencontrent lors des mêmes événements Scrum et utilisent des artéfacts similaires.

Problèmes d’élargissement et de Scrum@Scale
L’architecture sans échelle de Scrum@Scale signifie qu’elle permet d’élargir plus d’une fois. Si une organisation doit coordonner des équipes à une échelle encore plus grande, elle peut mettre en place un Scrum des Scrums.
Cependant, élargir Scrum, comme toute autre méthodologie de gestion, a ses défauts, et dans ce cas, ils sont similaires à ceux des équipes Scrum de base, seulement ils sont proportionnellement plus grands. C’est pourquoi nous recommandons de travailler les détails de la collaboration au sein de chaque équipe Scrum avant de commencer Scrum à une plus grande échelle. Nous suggérons d’élargir Scrum pour des équipes expérimentées qui ont une bonne connaissance et compréhension des valeurs et du fonctionnement de Scrum.

Élargir Scrum – résumé
Élargir Scrum n’est pas un jeu d’enfant. Cela nécessite que les équipes Scrum appliquent de manière compétente les principes Scrum et synchronisent leurs tâches avec d’autres équipes Scrum. Par conséquent, la question de base à laquelle répondre est : Est-ce que l’élargissement est nécessaire ? Juste parce qu’il y a de nombreuses équipes Scrum dans une organisation ne signifie pas automatiquement que les coordonner apportera de meilleurs résultats.
Si une organisation choisit d’augmenter Scrum, elle gagne une architecture sans échelle qui peut être augmentée avec succès davantage. Cependant, chaque augmentation s’accompagne d’une augmentation du niveau de complexité que l’équipe Product Owner, le Chief Product Owner et le Scrum des Scrums Master doivent gérer.
Si vous aimez notre contenu, rejoignez notre communauté de abeilles occupées sur Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.
Caroline Becker
En tant que chef de projet, Caroline est une experte dans la recherche de nouvelles méthodes pour concevoir les meilleurs flux de travail et optimiser les processus. Ses compétences organisationnelles et sa capacité à travailler sous pression font d'elle la meilleure personne pour transformer des projets compliqués en réalité.
Scrum Guide:
- Glossaire des termes, rôles et notions de base
- Qu'est-ce que Scrum ?
- Valeurs Scrum
- Comment mettre en œuvre Scrum dans votre entreprise ?
- Équipe Scrum - qu'est-ce que c'est et comment ça fonctionne ?
- Qui est un Product Owner ?
- Les erreurs les plus courantes du Product Owner
- Qui est le Scrum Master ?
- Les erreurs les plus courantes des Scrum Masters
- Quelles statistiques et métriques le Scrum Master devrait-il suivre ?
- Équipe de développement en Scrum
- Les erreurs les plus courantes des développeurs
- Artifacts Scrum
- Élargir Scrum
- Backlog de sprint
- Qu'est-ce que le Product Backlog ?
- Qu'est-ce que les User Stories ?
- Créer la meilleure User Story avec INVEST
- Les erreurs les plus courantes dans les User Stories
- Critères d'acceptation de l'histoire utilisateur
- Estimation et Points d'Histoire dans Scrum
- Planning Poker
- Jeu d'estimation d'équipe
- Définir l'incrément
- Événements Scrum
- Qu'est-ce qu'un graphique d'avancement ?
- Avantages et inconvénients du graphique de burndown
- Tableaux Kanban dans Scrum et Scrumban
- Vélocité en Scrum - Vitesse de l'équipe de développement
- Scrum quotidien
- Planification de Sprint
- Revue de Sprint
- Qu'est-ce qu'une rétrospective de sprint ?
- Erreurs courantes lors d'une rétrospective de Sprint
- Nourrir le backlog produit
- Comment créer et interpréter un graphique de burndown ?
- Qu'est-ce qu'un Sprint dans Scrum ?
- Coopération entre le Product Owner et le Scrum Master
- Engagements de l'équipe Scrum - Objectif produit, objectif de sprint et définition de la complétion
- Caractéristiques d'un bon Scrum Master