Le Scrum of Scrums a été présenté comme un « daily des équipes ». Mal conduit, il devient une réunion de reporting inutile. Voici ce qui le rend efficace.

Le bon objectif

Il ne sert pas à faire le point sur l'avancement de chaque équipe — chacune a son propre daily pour ça. Il sert à traiter ce qui se passe entre les équipes : dépendances, blocages partagés, risques de non-assemblage.

Trois questions inter-équipes

Chaque représentant répond, du point de vue de son équipe :

• Qu'avons-nous fait qui pourrait affecter les autres équipes ?
• Qu'allons-nous faire qui va les affecter ?
• De quoi avons-nous besoin d'une autre équipe, et pour quand ?

Qui vient

Un représentant par équipe — souvent un développeur, pas forcément le Scrum Master, et de préférence tournant, pour diffuser la vision d'ensemble. Pas toute l'équipe.

La cadence

Deux à trois fois par semaine suffisent le plus souvent. Tous les jours, c'est trop ; une fois par semaine, les dépendances sont détectées trop tard.

La synchronisation des priorités, à part

Le Scrum of Scrums traite l'exécution. L'alignement des priorités entre équipes se fait dans une autre instance, réunissant les Product Owners (parfois appelée « meta scrum » ou « PO sync »).

Quand ça ne suffit plus

Au-delà de cinq à sept équipes, le Scrum of Scrums devient ingérable. C'est le signe qu'il faut soit réduire les dépendances (leçon suivante), soit adopter un cadre à l'échelle plus structuré.

Exemple concret : trois équipes travaillent sur la plateforme de fidélité (application cliente, back-office marchand, moteur de points). Leur Scrum of Scrums, le lundi et le jeudi, révèle que l'équipe application a besoin d'une nouvelle donnée du moteur de points pour son sprint suivant : la demande est calée dès maintenant, pas découverte à la revue.

À vous de jouer : citez les trois questions inter-équipes auxquelles répond un représentant en Scrum of Scrums.