Un sujet que beaucoup évitent, soit parce qu'ils ne sont pas assez nombreux pour ça, soit parce que les équipes travaillent de manière isolée : les équipes Scrum multiples. Découvrez comment éviter les écueils qui vous mènerait à subir cette multiplicité.

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