Scrum of Scrum : Coordonner plusieurs équipes

Ecrit par << Paquet Judicaël >>

Mettre des équipes Scrum est une première étape dans l’organisation d’équipes Agile mais dans les grosses structures, il sera indispensable de faire travailler plusieurs équipes Scrum ensemble. La méthode du Scrum of Scrum va vous aider dans cette tâche.

Cette deuxième étape pour coordonner plusieurs équipes Scrum n’est pas si évidente que ça mais il existe des méthodes d’organisation qui vous aiderons à le faire.

La problématique de la complexité

Toute équipe qui travaille dans un Scrum avancé ne parle plus en temps mais en complexité (appelée aussi point d’effort). Du coup à première vue on voit la première difficulté arriver : comment créer une roadmap de plusieurs équipes Scrum en même temps alors qu’on ne parle pas en temps ?

Il est vrai qu’il ne faut pas oublier un point majeur du concept de la complexité : chaque équipe a son référentiel sur la complexité de ses user-story. Une complexité 3 dans une équipe 1 n’est pas forcément la même que dans l’équipe 2 (c’est très probable d’ailleurs que ce soit le cas).

Nous allons donc tenter de régler ce problème avant même de parler de dépendance entre les user-story afin de partir sur de bonnes bases.

Coordonner les complexités

 

Si convertir une complexité en temps n’a aucun sens, créer un ratio pour avoir une estimation de temps sur la globalité des complexités « Done » des 3 derniers sprint en a déjà beaucoup plus. Ce ne sera pas une science parfaite mais ça permettra déjà de se faire une bonne idée de la roadmap.

Pour calculer ce ratio de chaque équipe, nous allons faire ce calcul :

Ratio = CA3 / V3
    • V3 : Moyenne vélocité (total des complexités « Done ») sur 3 sprints
    • CA3 : Moyenne Capacité de production sur 3 sprints (nombre de jour homme)

Ce ratio unique pour chaque équipe va nous permettre de planifier un projet complet qui implique X équipes Scrum.

Désolé des termes peu être un peu complexe mais tous ces ratios vont permettre de créer ce qu’on appelle une complexité release soit une complexité de référence pour toutes les équipes.

Si ce n’est pas très clair, pas de panique, je vais vous donner un exemple sur un projet incluant 3 équipes Scrum différentes.

Nous commençons par calculer le ratio de chaque équipe en suivant la formule précédente pour avoir le résultat suivant :

ratio équipe 1 : 0,72
ratio équipe 2 : 1,5
ratio équipe 3 : 0,2

Et maintenant nous allons calculer la complexité release (CR) nécessaire pour chaque équipe pour réaliser une user-story de complexité 3  :

CR équipe 1 = 3 * 0.72 = 2.16
CR équipe 2 = 3 * 1.5 = 4.5
CR équipe 3 = 3 * 0,2 = 0.6

Dans un référentiel commun, la complexité 3 de l’équipe 1 sera en réalité de 2,16 alors que la complexité 3 pour la deuxième équipe sera de 4,5.

Celui reflète bien le fait que l’équipe 1 mettra probablement moins de temps pour résoudre une complexité de 3 que l’équipe 2 (n’oubliez pas, cela n’a de sens que sur plusieurs sprint et pas sur une seule user-story).

Je reconnais que cette notion est assez complexe mais en la mettant en pratique vous comprendrez rapidement son intérêt.

Pour reprendre notre exemple, cette complexité release va nous permettre de déterminer des sprint release qui contient l’ensemble des équipes concernées par ce projet. On pourra d’ailleurs en profiter pour tenir un Burndown Chart du Sprint release.

La vélocité release permettra de planifier des sprint release comme le faisiez avec un Sprint classique.

Premières problématiques rencontrées

Si votre équipe travaille sur d’autres choses que le projet alors en effet il y aura des trous dans le sprint release. Evidemment il faut éviter cela et revoir peut-être l’organisation de chaque équipe.

Je conseille pour ma part si il y a une obligation de correctifs de bugs et/ou de TMA de mettre un kanban en place pour mettre le nombre de personne de l’équipe suffisante dessus pour gérer le flux d’entrée (personnes qui du coup sortent du Scrum). Cela n’empêche pas bien au contraire de laisser ces personnes du Kanban participer aux différentes cérémonies de l’équipe Scrum (le but n’étant pas d’isoler ces personnes). Il est souvent plus agréable de faire tourner les personnes du Kanban à chaque démarrage de Sprint.

Organiser un Sprint Release

Pour déterminer un Sprint Release, nous allons tenter d’intercaler au mieux ce Sprint release par rapport à nos différentes équipes.

Voici un exemple simple quand les Sprint sont assez similaires entre les équipes :

Sprint release
Sprint release

Ici pas de soucis, c’est un des cas pratiques les plus simples à mettre en place. Je pense que ce schéma vous permet de bien comprendre l’idée de Sprint Release entre 3 équipes. Pour simplifier, on prend plutôt le Sprint le plus long en référence.

Dans d’autres cas, il sera impossible de trouver un compromis entre les équipes pour tenter d’avoir des Sprints communs. Il faudra alors faire le maximum pour que le Sprint Release soit le mieux calé possible.

Voici un exemple possible avec nos 3 équipes :

Sprint Release Complexe
Sprint Release Complexe

On va considérer que cette méthode est valable jusqu’à 9 équipes au total.

Mais si j’ai plus de 9 équipes impliquées sur un projet ?

C’est un cas qui sera extrêmement rare mais si ça venait à arriver, il faudra alors rajouter une couche au dessus qu’on appelle les Sprint Super Release (release de release en cascade).

Par contre pour des raisons évidentes de visibilité, vous ne pourrez pas faire un board  de Super Release détaillé à la user-story ; il faudra privilégier que ce board ne contienne que des Epics ou des thèmes.

Voici un schéma de ce concept plutôt simple à comprendre :

Super Release
Super Release

Maintenant que vous avez bien saisie l’idée, nous allons passer à la suite car ce n’est pas fini.

Pour mettre ce type d’organisation, il faudra beaucoup plus de monde que ce soit au niveau coaching et sur les rôles d’organisation car c’est très complexe à mettre en place.

Le Scrum of Scrum

Si toute l’organisation que nous avons vu participe à la mise en place de projets sur plusieurs équipes, il y a également la notion de Scrum of Scrum qui vient aider grandement à ce type d’organisation.

Le Scrum of Scrum propose de faire une Daily Release tous les 2 jours qui n’invitera par contre qu’un ambassadeur de chaque équipe. Celui-ci sera la voix de son équipe lors de cette cérémonie. On appliquera le même concept si on a encore un niveau supérieur dans la hiérarchie d’organisation du projet.

Vous l’aurez compris, la Daily Release doit respecter les mêmes règles qu’une Daily Scrum classique. Il est fortement conseillé d’avoir d’ailleurs un Scrum Master pour accompagner ces Daily Release (celui qui voudra le faire).

Voici un schéma simple à comprendre :

Scrum of Scrum
Scrum of Scrum

Si le Scrum of Scrum a pour but d’améliorer la transparence au maximum et d’éventuellement remonter des alertes, il faut tout de même pas oublier le travail à réaliser du côté des Product Owner.

Dans les Scrum avancés, chaque équipe a son Product Owner et ceux-ci devront alors se réunir 1 fois par semaine pour faire un comité PO. Cela permettra de coordonner leurs idées et de travailler ensemble dans la même direction.

On recommande dans ce cas d’avoir un CPO (Chief Product Owner) qui permettra de coordonner tout le travail des Product Owner.

Il arrive de voir dans les grandes structures, le Product Owner être au niveau des métiers ; dans ce cas, si il est le seul Product Owner de l’ensemble des équipes, vous en conclurez que ce comité est inutile.

Derniers conseils

Je l’ai dit brièvement mais il est recommandé de déterminer un Super Scrum Master qui animera les cérémonies des Release (Daily Release, Retrospective Release…). Il est possible que ce soit le Scrum Master d’une des équipes.

Faire des rétrospectives release est très important entre les ambassadeurs qui pourront d’ailleurs relever des problèmes lié au Scrum of Scrum qui ne seront pas forcément soulevés dans les rétrospectives de chaque équipe.

Il faut faire des Review Release pour présenter le travail général des équipes. Cette réunion a beaucoup de chance d’attirer plus de personne ayant des pouvoirs de décision. On y invitera les ambassadeurs, les PO (et CPO) et les clients.

Conclusion

Loin d’être facile à mettre en oeuvre, il existe comme vous le constatez des méthodes pour faire travailler plusieurs équipes Scrum entre elles.

Cependant, ce type d’organisation est assez complexe à mettre en place et je conseille fortement les entreprises à se faire accompagner pour avoir des résultats positifs. C’est à mon sens beaucoup plus complexe à mettre en place qu’une équipe Scrum.

 

6 réponses sur “Scrum of Scrum : Coordonner plusieurs équipes”

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *