Le document traite de la mise en place d'équipes Scrum multiples, en abordant les raisons valides et invalides d'élargir les équipes, ainsi que les défis organisationnels et de communication associés. Il propose diverses pratiques pour favoriser la collaboration entre équipes tout en soulignant les écueils à éviter, notamment la spécialisation excessive et la gestion des parties prenantes. Enfin, des questions clés sont posées concernant la composition des équipes et les interactions lors des réunions Scrum.

1. Equipes Scrum multiples
Comment les mettre en place?

2. Rappels
Une équipe Scrum …
• … comporte toutes les compétences
nécessaires à fournir un produit potentiellement
livrable à chaque sprint!
• … est composée idéalement de 5 à 9 personnes
+ 1 Product Owner

3. Pourquoi vouloir plus
d‘équipes?
• Les bonnes raisons!
• La vélocité des équipes actuelles ne suffit pas à fournir le périmètre voulu dans
les délais!
• La ou les équipes actuelles ont atteint une taille critique!
• Problèmes coûteux à contourner (distribution géographique, séparation de
responsabilité fonctionnelle, etc…)!
• Les mauvaises raisons!
• La vélocité des équipes n‘augmente pas assez vite!
• Spécialisation technique d‘une équipe!
• Problèmes humains (conflits, horaires, habitudes individuelles, etc…)!
• Difficultés contournable autrement

4. Idées reçues : c’est utile?
• Peu importe notre organisation, nous créerons le bon
produit!
• Conway’s law : “Organizations which design systems
are constrained to produce designs which are copies of
the communication structures of these organizations.”
• Scrum n’est pas fait pour les grosses équipes!
• Quelle méthode explique comment garder une bonne
dynamique d’équipe au-delà de 10 ? 20 ? 100
personnes?

5. Idées reçues : équipes
concurrentes ?
• Plusieurs équipes Scrum c’est compliqué!
• Plus que plusieurs équipes non Scrum?
• Plus qu’une très grosse équipe?
• Mettre en concurrence les équipes permet
l’émulation!
• Comment garantir une bonne collaboration
dans un contexte concurrentiel?

6. Idées reçues : dilution du
travail?
• Plusieurs équipes travaillant ensemble perdent
du temps à se synchroniser, font du travail en
double, etc…!
• Plusieurs équipes travaillant ensemble ?
• Notre organisation doit être bien pensée car
nous ne pourrons plus changer!
• Notre application doit être bien développée car
nous ne pourrons plus la changer?

7. Difficultés à prévoir : Vis-à-
vis des Principes agiles
!
• « Les meilleures architectures, spécifications
et conceptions émergent d'équipes auto-organisées »
• « Les utilisateurs ou leurs représentants et
les développeurs doivent travailler ensemble
quotidiennement tout au long du projet »
• « La méthode la plus simple et la plus efficace
pour transmettre de l’information à l'équipe de
développement et à l’intérieur de celle-ci est le dialogue
en face à face »

8. Difficultés à prévoir :
personnes
• Product Owner!
• Charge de travail
• Etre présents à toutes les réunions nécessaires
• Equipe Scrum!
• Moins d’autorité
• Grande ou distribuée
• Scrum Master!
• Plus de problèmes inter-équipe
• Dépendances
• Tout le monde!
• Augmentation des interactions

9. Difficultés à prévoir :
pratiques des équipes Scrum
• Backlog produit : plus gros, plus de complexité, plus d’acteurs possibles
• Sprint planning : Difficultés d’établir un objectif clair qui considère les autres
équipes
• Mêlée quotidienne : Distribution de chacun dans les équipes
• Tableau Scrum : Manque de place
• Revue de sprint : complexité logistique et timing
• Rétrospective de sprint : plus d’équipe, plus de problèmes, plus de solutions à
mettre en commun
• Définition de terminé : partage et évolution complexifiée
• Incrément produit : Dépendances par rapport aux autres équipes

10. Difficultés à prévoir :
difficultés liées à la charge
• Création de valeur : peut être contradictoire entre 2 équipes
• Indicateurs d’avancement : compromis multiplicité VS réconciliation
• Rôle de chaque équipe : séparation technique, fonctionnelle,
phasage ?
• Culturel / politique : pas de rôle hiérarchique au sein des équipes
• Développeurs : perte de paternité du code, conflits plus fréquents
• Objectifs d’équipes : moins d’influence individuelle
• Réutilisation : ne pas réinventer la roue

11. Séparation et répartition des
équipes
• Créer équipe pluridisciplinaire
• Toutes les compétences nécessaires à terminer une fonctionnalités
• Décidées par le management production …
• … avec la collaboration des équipes (dev + AM)
• Répartir les « experts »
• Eviter les temps partiels
• Eviter les équipes d’experts
• Distribuer l’expérience
• Scrum
• Développement

12. Travail au quotidien des
équipes
• Collaboration informelles inter-équipes
• Binômage, mêlée de mêlées, visites de mêlées
• Echanges entre équipes
• A chaque sprint, 2 membres de chaque équipe passent dans
l’autre équipe pour 1 sprint
• Le rôle de correspondant commence au sprint planning et se
termine au sprint planning suivant
• Communautés de disciplines (JS, DB, archi, tests, C#, SM, etc...)
• Mise en commun des problèmes à résoudre et des pratiques

13. Organisation des Sprints
• Tous les sprints de toutes les équipes sont synchronisés
• Toutes les réunions se font à la même heure pour toutes les équipes
• Si la taille de sprint d’une équipe n’est pas la même, elle doit pouvoir
se synchroniser sur les autres
Sprint 1
Sprint 1
Equipe Verte
Equipe Jaune
Equipe Grise Sprint 1.1 Sprint 1.2
Sprint 2
Sprint 2
Sprint 2.1 Sprint 2.2
Possibilité de Sprint Planning
commun
Possibilité de revue + livraison
commune

14. Organisation des mêlées
• Décalage des mêlées pour pouvoir « visiter » les mêlées des autres équipes plus
facilement
• Nécessité de terminer à l’heure plus forte encore
• Mêlée de mêlée à la fin (M²) avec un membre de chaque équipe
• Possibilité de créer plusieurs flux parallèles au delà de 3 équipes (M3)
15 min
15 min
15 min
9h30
9h45
10h00
Equipe Verte Equipe Jaune Equipe Grise
M² : 15 min
10h15

15. M² et M3: quel contenu ?
1. Qu’est-ce que votre équipe a fait
depuis notre dernière mêlée?
2. Qu’est-ce que votre équipe va faire jusqu’à la
prochaine mêlée?
3. Est-ce que quelque chose ralentit votre équipe?
4.Est-ce que quelque chose fait par votre équipe
va ralentir le travail d’une autre équipe?

16. Organisation des Sprint
Plannings
• Avant le sprint planning!
• Les AM prévoient la répartition par équipe pour le sprint
• Les équipes sont stables
• Sprint planning option 1 : tous ensemble!
• Inter équipe dans la phase « Quoi? »
• Un AM déroule le backlog (Programme Application Manager ou l’un des AM Référent de l’équipe)
• Les équipes estiment ensemble durant le déroulement
• A la fin, chaque équipe choisit la composition de son sprint
• Mono-équipe pendant la phase « Comment? »
• Idéal pour répartir une grosse charge de travail

17. Organisation des Sprint
Plannings
• Avant le sprint planning!
• Les AM prévoient la répartition par équipe pour le sprint
• Les équipes sont stables
• Sprint planning option 2 : chacun pour soi!
• Mono-équipe tout au long des phases « Quoi ? » et
« Comment ? »
• Chaque AM distribue une partie de travail à son équipe
• Idéal pour des équipes centrées sur des produits différents

18. Organisation des Revues de
Sprint
• Rassembler les revues de sprint lorsque les équipes
travaillent sur des produits interdépendants
• A priori toujours le cas
• Chaque équipe présente son travail à l’ensemble des
participants
• L’AM Référent de chaque équipe parle de l’avancement
et des perspectives de son application/périmètre
• Un AM conclut sur l’avancement globale et les
perspectives programme

19. Organisation des
Rétrospectives de Sprint
• Chaque équipe fait sa rétrospective dans son coin
• Il s’agit d’une inspection de sa manière de travailler
• Les interactions avec les autres {équipes, métiers, AM, activités} y sont aussi étudiées
• Si un AM est partagé entre plusieurs équipes, il passe d’une rétrospective à l’autre à
chaque Sprint
• La communauté de Scrum Master partage les points de chaque équipe pour mettre en
commun le travail
• A essayer pour accélérer l’amélioration inter-équipe
• Faire une rétrospective thématique commune par version (en milieu de version)
• Garder 15 minutes en fin de rétro pour visiter les tableaux d’idées des autres équipes
• Créer un « correspondant de rétrospective » tournant à chaque sprint

20. Jeu : Meddlers

21. Best practices++
• Stabilité des équipes
• Désigner un rapporteur pour les réunions importantes
• 1 AMR / Equipe (et seulement 1)
• Référentiel commun pour les produits interdépendants (voire pour tous les produits)
• Definition of Done
• Backlog (Priorités, Systèmes d’estimation en points ou t-shirt)
• Impediments et actions
• Déplacer les User Stories dans l’autre équipe plutôt que les personnes
• Synchronisation des AM (PO) avant chaque:
• Revue de BL
• Sprint planning
• Démo

22. Worst practices
• Essayer de travailler avec trop de parties prenantes (ou plusieurs AM référents) pour une seule équipe
• Nécessité de séparation?
• Essayer d’imposer une manière unique de travailler à toutes les équipes
• Les pratiques peuvent être fédérées, mais jamais unifiées
• Comparer le travail des équipes entre elles
• Un sprint d’une équipe ne ressemble jamais au précédent, alors que dire de ceux de 2 équipes?
• Favoriser l’adoption des bonnes pratiques d’une équipe à l’autre est plus efficace que de les monter les
unes contre les autres
• Spécialiser une équipe techniquement ou par module
• Que faire quand la quantité de travail fluctue? Quand le périmètre est transverse? Quand un bug survient?
• Une spécialisation ne peut être que fonctionnelle, et ne pas poser de barrière
• Négliger la rapidité engendrée par la stabilité
• Trop de changements de composition des équipes perturbe les repères et les habitudes, et donc la vélocité

23. Best questions
• Composition des équipes : à chaque sprint ? À chaque version ? Dès que le besoin est ressenti ?
• Affectation à une équipe : imposée ? Décidée par les membres ?
• Spécialistes : temps partiel dans chaque équipe ? Dans une équipe de spécialiste à part ? Dans une des
équipes pluridisciplinaires ?
• AMR (PO) : dans une équipe spécialisée ? Un pour toutes les équipes ? Un facilitateur (~ scrum master) PO ?
• Faisons nous notre sprint planning en commun ?
• Faisons nous notre revue de sprint en commun ?
• Les équipes font elles leurs mêlées en même temps ? De manière décalée ? Dans la même « période de la
journée » ?
• Qui fait le mêlées de mêlées ?
• Qui synchronise les actions d’équipe ?
• Un AM peut-il être Référent pour 2 équipes en même temps ?
• A quel moment affecte-t-on les User Stories à une équipe ou à une autre ? (tip : décision des AM, sprint
planning 0 inter équipe ou sprint planning 3 inter équipe)

24. Liens utiles
• Scaling Scrum - Colin Bird & Rachel Davies - Scrum Gathering London 2007 - http://
www.scrumalliance.org/resource_download/287
• Why Having Multiple Product Owners Is a Bad Idea - http://brodzinski.com/2010/05/
multiple-product-owners-bad-idea.html
• Scrum et XP depuis les tranchées – Henrick Kniberg - http://henrik-
kniberg.developpez.com/livre/scrum-xp/?page=multi-scrum
• Scaling Scrum with Feature Teams - http://www.odd-e.com/material/2009/
JAOO_Scaling_Scrum_with_feature_teams/2009_JAOO_print_small.pdf
• Product Owner Anti-Patterns, Part 3: No Single Product Owner - http://
www.solutionsiq.com/resources/agileiq-blog/bid/58999/Product-Owner-Anti-Patterns-
Part-3-No-Single-Product-Owner
• Scrum it, Scale it - Danny (Danko) Kovatch - http://www.scrumalliance.org/system/
resource_files/0000/0463/
Danny_Danko_Kovatch_Scaling_Scrum__Compatibility_Mode_.pdf