14 septembre 2021
Rappelons tout d’abord que Scrum, n’est pas une méthode agile mais fournit un cadre comprenant des rôles, des événements, des artefacts pour aider à respecter les quatre valeurs et les douze principes listés dans le manifeste agile.
Vous pouvez consulter cet article pour savoir comment choisir une méthode agile.
On pourrait penser qu’il est de la responsabilité du Scrum Master d’organiser et d‘animer tous les événements…
Qu’en est-il exactement ?
Faut-il répartir l’animation des quatre événements entre les trois rôles définis par Scrum ?
Le framework Scrum définit trois rôles :
Le framework Scrum propose quatre événements :
Nous y voilà !
Tous les événements Scrum doivent-ils obligatoirement être animés par le Scrum Master ?
Concernant les événements, le Scrum Master, garant du respect de la compréhension et de l’application de la méthode agile choisie, doit s’assurer que les événements se tiennent conformément à l’agenda de Sprint. Mais il n’est clairement pas obligé d’organiser et d’animer tous les événements.
Voyons ce que pourrait être une répartition raisonnable de l’animation des événements entre les trois rôles :
Usuellement, le Scrum Master positionne l’événement du Daily dans les calendriers des personnes du projet. Il peut donc s’occuper de la partie logistique en prenant soin de réserver une salle par exemple.
Mais l’animation du Daily est du côté de l’équipe de réalisation. Aux membres de l’équipe de prendre spontanément la parole devant le tableau Kanban du Sprint et de faire vivre cet événement. A eux de communiquer de manière fluide et dynamique sur l’avancée et la bonne marche du Sprint en cours et partager ce point de suivi à toute personne assistant, de manière passive, à l’événement.
Il n’est d’ailleurs pas rare que ni le Scrum Master, ni le Product Owner ne prennent la parole s’ils ne sont pas sollicités de manière explicite par l’équipe.
Au cours du Sprint Planning, tout le monde intervient quel que soit son rôle !
Mais l’animation proprement dite doit se faire entre le Scrum Master et le Product Owner.
Le Product Owner présente les éléments du backlog en commençant forcément par le premier d’entre eux puisque le backlog est toujours priorisé et ordonné. Il rappelle le sujet global, partage la description et les critères d’acceptation dans le but de provoquer les échanges et ainsi parvenir au besoin définitif avant un éventuel engagement dans le Sprint
Le Scrum Master de son côté a la charge de veiller au bon déroulement du Planning Poker. Il s’assure que tous les membres de l’équipe estime l’effort de chaque élément de backlog en votant simultanément avec les autres afin de ne pas subir une quelconque influence. Il doit également initier le débat en cas d’estimations extrêmes en demandant aux personnes concernées de justifier et d‘expliquer leur vote.
Là encore, au cours de la Démo, tous les membres de l’équipe de réalisation interviennent en montrant leurs réalisations du Sprint afin de prouver que l’objectif du Sprint est atteint et que les dernières réalisations apportent bien de la valeur au produit.
Mais c’est essentiellement le Product Owner qui va piloter et animer cet événement. Et dans ce cas précis, on pourrait même dire que le Product Owner « s’occupe de tout » !
Ça commence par l’établissement de la liste des personnes à inviter pour la Démo. On l’oublie parfois mais le Product Owner possède également un rôle de « commercial » qui doit vendre son produit, en interne comme en externe. Plus il parvient à attirer du monde lors des démos, mieux c’est pour le projet. Les membres de l’équipe se sentiront valorisés et sauront que le projet sur lequel ils travaillent est important voire stratégique. Et plus de parties prenantes, plus de personnes présentes signifie mathématiquement plus de retours, plus de critiques, plus d’avis qui seront pris en compte par le Product Owner pour apporter toujours plus de valeur au produit.
Il n’est pas recommandé lors de la Démo à chercher à tout montrer. Certaines tâches purement techniques ne « parleraient » pas suffisamment à l’ensemble des personnes assistant à la Démo. Le Product Owner définit souvent un scénario de démonstration qui consiste à enchaîner les présentations par les membres de l’équipe des différents sujets qui permettent de prouver que l’objectif du Sprint est atteint.
A la fin, le Product Owner valide le contenu de la Démo.
Encore une fois, bien sûr que tout le monde va participer ! C’est même clairement le but recherché.
Ici, c’est le Scrum Master qui doit animer cet événement privé qui ne concerne que l’équipe de réalisation, le Product Owner et le Scrum master.
Le Scrum Master va animer cet événement de bout en bout en commençant par faire un point de suivi des actions décidées lors de la précédente Rétro. Rien de pire pour une équipe d’enchaîner les Rétros sans pouvoir constater les bénéfices attendus des actions engagées !
Ensuite, il faut parvenir à faire émerger les idées, les constats parfois négatifs afin de pouvoir dégager des axes d’amélioration. Pour cela, le Scrum Master doit animer en faisant preuve d’imagination, notamment en variant les formats proposés pour la Rétro. Il endosse clairement le rôle de maître du débat et veille à ce que tout le monde puisse s’exprimer, même et surtout les personnes les plus réservées.
Enfin, animer la Rétro consiste aussi à trouver des responsables pour l’exécution et le suivi des actions décidées par l’équipe. Et si possible sur la base du volontariat !
Le but de la matrice de répartition ci-dessous n’est pas de lister les actions exhaustives des trois rôles pendant les quatre événements mais uniquement indiquer quel rôle anime quelle partie de ces événements.
| Scrum Master | Product Owner | Equipe de Réalisation | |
|---|---|---|---|
| Sprint Planning | Anime le Planning Poker | Anime par la présentation des éléments du backlog | |
| Daily Meeting | Anime par la prise de parole successive des membres | ||
| Sprint Review | Anime par la présentation du scénario retenu pour la Démo | ||
| Sprint Retrospective | Anime les quatre étapes de la Retro (Recueil des avis, regroupement, vote, actions correctives) |
Cette matrice, et plus généralement le contenu de cet article, ne représente bien sûr que des indications. Des équipes pourront choisir une autre répartition des événements Scrum… N’oublions pas l’un des principes essentiels de l’agilité : les équipes agiles sont auto-organisés.
Le guide Scrum 2020 a été mis à jour récemment et présente les évolutions par rapport au guide de 2017.
A vous de jouer !!!