Mettre des équipes Scrum est une première étape dans l’organisation d’équipes Agile. Cependant dans les grosses structures, il sera indispensable de faire travailler plusieurs équipes Scrum ensemble. La méthode du Scrum of Scrum (Sos) va vous aider dans cette tâche.
Cependant de nos jours, de nombreux framework scrum existent et sont souvent plus populaires que cette méthode vue comme vieillissante. Vous pourrez regarder du côté du LeSS, Nexus, SAFe…
Articles :
Qu’est ce que le framework agile LeSS ?
L’agilité à l’échelle avec LeSS Huge
Le framework Nexus
Qu’est-ce que le framework SAFe 4.5 ?
SAFe 4.6 est de sortie
Le Scrum à grande échelle avec SSwS
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.
D’ailleurs, vous pouvez regarder notre vidéo sur ce sujet :
La problématique de la complexité
Toute équipe qui travaille dans un Scrum avancé ne parle plus en temps mais en 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 que nous ne parlons pas en temps ?
Il est vrai qu’il ne faut pas oublier un point majeur du concept du point d’effort : chaque équipe a son référentiel sur les points d’effort de ses user-stories. Un point d’effort 3 dans une équipe 1 n’est pas forcément le 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-stories afin de partir sur de bonnes bases.
Coordonner les complexités en Scrum of Scrum (Sos)
Si convertir un point d’effort en temps n’a aucun sens, créer un ratio pour avoir une estimation de temps sur la globalité des points d’effort « 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 estimative (vision sur l’avancement désiré).
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 un point d’effort release soit un point d’effort 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.
Exemple de calcul
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 le point d’effort release (PER) nécessaire pour chaque équipe pour réaliser une user-story de complexité 3 :
PER équipe 1 = 3 * 0.72 = 2.16 PER équipe 2 = 3 * 1.5 = 4.5 PER équipe 3 = 3 * 0,2 = 0.6
Dans un référentiel commun, le point d’effort 3 de l’équipe 1 sera en réalité de 2,16 alors que le point d’effort 3 pour la deuxième équipe sera de 4,5.
Cet exemple reflète bien le fait que l’équipe 1 mettra probablement moins de temps pour résoudre un point d’effort 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, ce point d’effort release va nous permettre de déterminer des sprint release ; ceux-ci contiennent l’ensemble des équipes concernées pour 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 en Scrum of Scrum
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. Cela permettra de 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 ; enchainer des semaines de TMA peut rapidement devenir un calvaire pour les membres de l’équipe travaillant dessus.
Organiser un Sprint Release en Scrum of Scrum
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 :
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 :
On va considérer que cette méthode est valable jusqu’à 9 équipes au total.
Le Sprint Super Release du Scrum of Scrum
Mais si nous avons plus de 9 équipes impliquées sur un projet ?
C’est un cas qui sera extrêmement rare mais si cela venait à arriver, il faudra alors rajouter une couche supplémentaire. On appelle cela des 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 :
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 (Sos)
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 ; on n’y 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 :
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 ayant des produits différents a son Product Owner ; 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) ; il 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 pour votre Scrum of Scrum (Sos)
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és 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 personnes ayant des pouvoirs de décision. On y invitera les ambassadeurs, les PO (et CPO) et les clients.
Conclusion Scrum of Scrum (SoS)
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. 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.
7 Rétroliens / Pings