Equipes Scrum multiples

Comment les mettre en place?

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

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

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?

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?

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?

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 »

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

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

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

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

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

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

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 min10h15

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?

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

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

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

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

Jeu : Meddlers

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

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é

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)

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