Equipes scrum multiples upwiser

601 vues

Publié le

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é.

Publié dans : Logiciels
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
601
Sur SlideShare
0
Issues des intégrations
0
Intégrations
43
Actions
Partages
0
Téléchargements
4
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Equipes scrum multiples upwiser

  1. 1. Equipes Scrum multiples
 Comment les mettre en place?
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. Jeu : Meddlers
  21. 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. 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. 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. 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

×