---

Qu’est-ce que la coordination et la planification multiéquipes ? Cela pourrait vous surprendre !

Scrum of Scrums

Après le chapitre précédent, vous vous demandez sans doute comment coordonner ces équipes Scrum pour qu’elles collaborent efficacement.

C’est une question légitime, à laquelle nous avons aussi tenté de répondre.

Réunions Scrum of Scrums

Elles ressemblent au Daily Scrum. Mais elles portent sur les équipes elles-mêmes plutôt que le travail individuel des membres.

Le Scrum of Scrums est une pratique facultative de coordination, pas un événement formel supplémentaire. Une durée quotidienne de 15 minutes est possible ; un besoin accru peut justifier 30 à 60 minutes. Les équipes doivent vérifier l’utilité du format.

Exemples de questions de coordination

• Qu’a fait l’équipe hier ?
• Que prévoit-elle aujourd’hui ?
• Des obstacles ralentissent-ils ou empêchent-ils sa progression ?

Les réponses doivent couvrir les User Stories et dépendances qui affectent les autres équipes.

Dans ce modèle historique, Chief Scrum Product Owner et Lead Scrum Master peuvent faciliter ensemble le Scrum of Scrums. Ces titres organisationnels sont facultatifs, pas des responsabilités Scrum supplémentaires. L’un d’eux peut aussi faciliter seul ou alterner cette responsabilité avec l’autre.

Revues de Sprint communes

Ces revues avec toutes les équipes sont facultatives mais utiles. La finalité du Sprint Review reste obligatoire. Les équipes d’un produit inspectent ensemble leur résultat intégré avec les parties prenantes ; des séances locales séparées ne sont pas un doublon imposé.

Les participants sont les délégués des équipes et le Product Owner responsable du produit commun. Les parties prenantes participent aussi à l’inspection.

Les équipes peuvent faire tourner leurs délégués selon leurs préférences. Un facilitateur désigné, comme le Lead Scrum Master facultatif de cet exemple, peut aider à rendre la revue commune efficace.

Toutes les équipes peuvent présenter leurs incréments livrables au Product Owner responsable, aux contacts produit et aux parties prenantes concernées.

Les revues communes remplissent ainsi deux fonctions :

1. Toutes les équipes partagent l’état global du projet.
2. Elles recueillent des retours à intégrer aux prochaines planifications de Sprint.

Rétrospectives de Sprint communes

Les rétrospectives communes sont, elles aussi, facultatives mais potentiellement très utiles.

Elles ne remplacent pas les rétrospectives nécessaires à chaque Scrum Team.

Les délégués des équipes participent et peuvent tourner à leur discrétion.

Un coordinateur désigné, comme le Lead Scrum Master facultatif de cet exemple, peut les faciliter. Elles cherchent et mettent en œuvre les améliorations de l’utilisation de Scrum par la grande organisation projet.

Les problèmes nécessitant plusieurs équipes (en savoir plus sur Plusieurs Scrum Teams) doivent y être mis en évidence. Leur résolution doit être planifiée, programmée et suivie.

Planification multiéquipes : le Scrum Product Backlog global

Les équipes d’un produit partagent un Product Goal et un Product Backlog sous un seul Product Owner responsable. Cette leçon appelle cette vue commune le Backlog global. Contacts produit et équipes peuvent affiner son contenu, mais la responsabilité reste au Product Owner.

Backlogs propres aux équipes

Si nécessaire, les User Stories du Backlog global peuvent être découpées en stories plus spécifiques aux équipes.

Les détails figurent dans des vues de travail et, après sélection, dans le Sprint Backlog de chaque équipe. Ces vues renvoient au Backlog commun, sans former des Product Backlogs du même produit hiérarchisés indépendamment. Ces références montrent la place des stories dans l’ensemble du projet et la valeur client livrée.

Planifier le calendrier des Sprints

À distance, deux options permettent de synchroniser le travail des équipes Scrum.

• Sprints synchrones
• Sprints asynchrones

Avec des Sprints synchrones, toutes commencent et finissent le même jour.

Cette option est généralement préférée, car elle facilite communication et coordination.

Sprints synchrones

Avec des Sprints asynchrones, elles ne commencent et ne finissent pas le même jour. Les événements n’ont donc pas tous lieu le même jour, permettant au Product Owner et aux contacts de coordination de participer aux planifications, revues et rétrospectives des autres équipes et de les aider sur demande.

L’asynchronisme apporte aussi un avantage lorsqu’une équipe fournit des services aux autres.

Sprints asynchrones

L’illustration le montre : le travail de l’équipe A, fournisseur, doit être intégré aux livrables de l’équipe B, principale. L’équipe A termine son Sprint avant B, qui peut alors intégrer les livrables avant de clore le sien.

Estimations d’effort

Les équipes peuvent choisir une convention commune, comme points de Fibonacci ou tailles de t-shirt, si elle aide la planification. Scrum ne l’impose pas ; points et vélocités ne sont pas automatiquement comparables entre équipes.

Lorsqu’une convention commune est utile, appliquez-la uniformément au Product Backlog partagé tout en préservant la responsabilité d’estimation des Developers.

Soyez attentifs aux estimations des équipes de composants, qui servent généralement les stories des équipes de fonctionnalités. Elles doivent obtenir soutien et clarifications pendant leur propre planification et estimation.