L'organisation

Le Scrum Master

Le Scrum Master n'a aucune autorité sur l'équipe, et Scrum en fait pourtant une responsabilité à part entière. Cinq patterns d'A Scrum Book décrivent son travail : aider chacun à comprendre Scrum, s'effacer pour que l'équipe prenne sa réunion quotidienne en main, la sortir de l'autosatisfaction, écarter un « héros » qui fait de l'ombre aux autres et se faire lui-même accompagner.

Une réunion où tout le monde regarde la même personne

Chaque matin à 9 h 15, les six développeurs qui maintiennent le logiciel de facturation d'une régie des eaux se retrouvent debout devant leur tableau. Sandrine, ancienne chef de projet, est leur Scrum Master depuis deux mois. Elle tient un carnet.

Karim parle en la regardant : « Hier, j'ai terminé le calcul des relevés estimés. Aujourd'hui, je passe aux factures rectificatives. » Sandrine hoche la tête et note. Julie enchaîne : « Je suis toujours bloquée sur l'import des compteurs. Sandrine, qu'est-ce que je fais ? » Les cinq autres attendent la réponse de Sandrine.

Un matin, Sandrine se place derrière Julie au lieu de lui faire face. Julie se retourne, hésite, puis finit par s'adresser à ses collègues. La semaine suivante, Sandrine ne vient pas et prévient l'équipe que cette réunion lui appartient. Les deux premiers jours sont laborieux. Le troisième, Karim dit à Julie : « L'import des compteurs, je l'ai écrit l'an dernier. On regarde ensemble après la réunion. »

Le pattern ScrumMaster : quelqu'un qui regarde comment l'équipe travaille

A Scrum Book (2019) décrit Scrum sous forme de patterns, qui exposent chacun un problème récurrent, les forces en jeu et une solution tirée de l'expérience. Le pattern ScrumMaster (littéralement « maître de mêlée », le scrum étant la mêlée du rugby), que le livre écrit en un seul mot, porte deux étoiles : les auteurs pensent qu'une équipe Scrum finira par en avoir besoin.

Le problème. Le Product Owner (la personne qui ordonne ce qu'il faut construire) s'occupe du marché, et les développeurs s'occupent des techniques de fabrication. Aucun des deux n'a pour mission d'examiner leur façon de travailler ensemble. Or ni l'équipe ni l'organisation ne tirent profit de Scrum sans en comprendre et en appliquer les principes.

Les forces. Il est difficile de voir un problème dont on fait soi-même partie, et un regard détaché aide à le repérer. Les rôles, les réunions et les listes ne sont que la partie visible de Scrum, et les principes qui les justifient sont souvent ignorés. Une équipe en bonne santé demande aussi des travaux que personne ne réclame, comme lever un obstacle ou arbitrer un désaccord. Quand ils échoient à des managers, ceux-ci apportent avec eux une relation de contrôle. Enfin, chacun regarde son propre objectif et perd de vue le processus : quelques tests sont sautés, le Product Owner interrompt le travail « juste cette fois », et l'équipe s'y habitue. Le livre résume la situation en disant que Scrum a deux produits, le livrable et l'équipe, et que ce qui relève de tous finit par ne relever de personne.

La solution. L'équipe se dote d'un ScrumMaster qui guide le Product Owner, les développeurs et l'organisation dans la compréhension de Scrum, de ses principes et de ses valeurs. Il défend le processus, aide à lever les obstacles et explique les principes en jeu pour que l'équipe trouve elle-même sa solution. Il n'a d'autorité ni sur les développeurs ni sur le Product Owner. Le livre énumère ses activités : observer et poser des questions, faciliter, enseigner, intervenir et, la plus importante selon les auteurs, s'abstenir activement d'agir. Chaque fois que le ScrumMaster résout un problème à la place de l'équipe, celle-ci perd une occasion d'apprendre.

Le livre donne l'exemple d'un Product Owner qui n'a pas ordonné sa liste. Plutôt que de le lui réclamer, le ScrumMaster lui demande lequel de deux éléments compte le plus, compte tenu de ce que lui seul sait des finances et des utilisateurs. Les auteurs ajoutent que l'équipe choisit idéalement son ScrumMaster et peut le remplacer s'il ne l'aide pas à progresser. Ils doutent qu'une même personne puisse être à mi-temps ScrumMaster et à mi-temps développeur, parce qu'elle y perdrait son recul.

Ce que dit le Guide Scrum 2020

Dans le Guide Scrum de Ken Schwaber et Jeff Sutherland (édition 2020), le Scrum Master est redevable (il doit en rendre compte) de deux choses : la mise en place de Scrum tel que le Guide le définit et l'efficacité de la Scrum Team, l'équipe complète. Le Guide décrit les Scrum Masters comme de vrais leaders au service de la Scrum Team et de l'organisation, là où l'édition de 2017 parlait de « servant-leader ». Il détaille ce service envers l'équipe (l'accompagner vers l'autogestion, faire lever les obstacles, veiller à ce que les réunions aient lieu et tiennent dans leur durée), envers le Product Owner et envers l'organisation.

Trois écarts méritent d'être signalés. Le livre donne au ScrumMaster un pouvoir direct, celui de retirer un membre de l'équipe, que le Guide ne mentionne pas. Le livre souhaite que l'équipe choisisse son ScrumMaster, et le Guide n'en dit rien. Enfin, le Guide de 2020 admet que le Scrum Master travaille lui-même à des éléments du Sprint (la période de travail de durée fixe, d'un mois au plus), auquel cas il participe à la réunion quotidienne comme un développeur, alors que le livre se méfie de ce cumul.

ScrumMaster Incognito : s'effacer pendant le Daily Scrum

Le Daily Scrum est la réunion quotidienne de quinze minutes où les développeurs examinent leur avancement et ajustent leur plan. La scène d'ouverture illustre le pattern ScrumMaster Incognito (« le ScrumMaster incognito »). Il porte une étoile : les auteurs y voient le cœur d'une bonne solution, sans prétendre qu'elle soit la seule.

Le problème. Pendant le Daily Scrum, les développeurs s'adressent au ScrumMaster au lieu de se parler entre eux, et ils attendent une consigne ou une approbation avant d'agir. Ils ne se sont approprié ni la réunion ni le travail d'équipe.

Les forces. Les développeurs sont les mieux placés pour replanifier leur travail, mais faire un compte rendu est moins risqué que prendre une décision. L'habitude vient souvent d'une relation antérieure avec un chef de projet. On parle aussi plus volontiers à la personne dont on est sûr qu'elle écoute, c'est-à-dire à celle qui a tenu à organiser la réunion.

La solution. Le ScrumMaster, garant du processus, fait en sorte que l'équipe prenne la réunion en main. Il peut se rendre invisible, en se plaçant derrière la personne qui s'obstine à lui faire un rapport ou en quittant discrètement la pièce, et il peut aussi expliquer à l'équipe pourquoi cette appropriation compte. Sa présence n'est pas nécessaire. S'il assiste à la réunion, il n'intervient dans la planification que si on le lui demande, et sans orienter le choix des développeurs. Le Guide de 2020 va dans le même sens : le Daily Scrum y est une réunion des développeurs.

Deux interventions quand l'équipe stagne

S'abstenir d'agir est la règle, et le livre décrit deux situations où le ScrumMaster doit au contraire intervenir.

Pop the Happy Bubble : crever la bulle de satisfaction

Le pattern Pop the Happy Bubble (« crever la bulle heureuse ») ne porte aucune étoile : les auteurs le jugent utile et reconnaissent que d'autres solutions existent.

Le problème. Une équipe qui a progressé peut se satisfaire de ses améliorations. Les dysfonctionnements restants persistent alors, comme si une bulle la protégeait des informations désagréables.

Les forces. Le premier succès, par exemple livrer enfin quelque chose, fait paraître dérisoires les obstacles suivants. Les rétrospectives (les réunions où l'équipe examine sa façon de travailler) tournent à l'autocongratulation, puis disparaissent. L'équipe attribue ses échecs à des événements exceptionnels ou à des causes extérieures. Dans un groupe soudé, personne ne veut d'une conversation pénible. De plus, la bulle est transparente et ne se voit pas de l'intérieur.

La solution. Quelqu'un secoue l'équipe en lui montrant des faiblesses importantes, données à l'appui, puis construit avec elle un plan d'amélioration. Le ScrumMaster est bien placé pour le faire, parce qu'il voit l'ensemble et ne prend pas part aux décisions de fabrication. Le livre lui demande de dire « nous » et non « vous », et de préférer les questions aux solutions imposées. Si le ScrumMaster est lui-même dans la bulle, le regard du ScrumMaster d'une autre équipe peut la percer.

Les auteurs ne cachent pas les risques. Certains membres vivront l'intervention comme une pression injustifiée, la motivation peut chuter et des personnes peuvent quitter l'équipe.

Remove the Shade : quand un héros fait de l'ombre

Le problème du pattern Remove the Shade (« ôter l'ombre », une étoile) est le suivant : l'équipe repousse les décisions et les travaux importants jusqu'à ce qu'un membre particulièrement compétent soit disponible.

Les forces. L'organisation appelle toujours cette personne quand une affaire presse, puisqu'elle aura le dernier mot de toute façon. Les autres renoncent aux tâches difficiles. Le héros, comme un parent pressé, trouve plus simple de faire lui-même que d'apprendre aux autres. Il produit beaucoup, mais ses collègues restent à l'ombre et ne progressent plus, pendant que lui-même risque l'épuisement.

La solution. Le ScrumMaster retire le héros de l'équipe pour que les autres grandissent, comme des fleurs reçoivent la lumière après la chute d'un grand arbre, et l'organisation trouve un autre emploi à ses talents. Les auteurs admettent que la décision est difficile : la direction peut s'y opposer, le héros peut se sentir rétrogradé et la production baisse le temps que l'équipe prenne le relais. Ils rapportent le cas d'une entreprise danoise où la vélocité d'une équipe (la quantité de travail terminée par Sprint) a doublé après le départ d'un membre qui abattait cinq fois plus de travail que les autres. Il s'agit d'un témoignage et non d'une mesure contrôlée. Le livre propose aussi une version allégée : le héros renonce aux travaux où il excelle et se limite à conseiller, souvent en binôme.

Scrum (Master) Coach : le Scrum Master se fait aider

Le problème du pattern Scrum (Master) Coach (« le coach du ScrumMaster », une étoile) tient en une phrase : le ScrumMaster est parfois lui-même à l'origine des difficultés de l'équipe, ou il n'est pas à la hauteur, ou il veut simplement progresser.

Les forces. Beaucoup de ScrumMasters débutent, et le rôle a de nombreuses facettes. Les plus expérimentés retombent dans leurs routines. À force de côtoyer certains obstacles, le ScrumMaster finit par les trouver normaux.

La solution. Le ScrumMaster cherche régulièrement des occasions de réflexion avec un coach ou un partenaire d'entraînement. Ce peut être un autre ScrumMaster de l'organisation ou une personne extérieure, pourvu qu'elle ait assez de distance avec la situation. Elle n'a pas besoin d'être experte du sujet, car une bonne question débloque parfois mieux qu'une réponse. Le coach peut observer l'équipe, mais il n'intervient pas auprès d'elle. Le livre signale un effet secondaire : un comportement nouveau, comme l'écoute active, paraît d'abord peu sincère à ceux qui connaissaient l'ancien, et il faut du temps pour qu'il devienne naturel.

Limites et pièges

La dérive la plus fréquente est le chef de projet déguisé. Le Scrum Master distribue les tâches, collecte les avancements et rend compte à la direction, comme Sandrine au début.

La dérive opposée réduit le rôle à un secrétariat : réserver les salles, tenir l'outil de suivi à jour et rédiger les comptes rendus. « Ne rien faire » peut aussi servir d'excuse à la passivité, alors que le livre parle d'une abstention active, précédée d'observation et suivie de questions.

Les deux patterns d'intervention sont à manier avec précaution. Retirer une personne d'une équipe est une décision lourde, que le Guide Scrum ne confie pas au Scrum Master et qui relève, dans la plupart des organisations, de la hiérarchie et du droit du travail. Le livre demande d'ailleurs d'essayer d'abord l'accompagnement. Crever la bulle, de son côté, peut blesser si les données manquent ou si le ton accuse.

Enfin, l'utilité d'un Scrum Master à plein temps est discutée, et la recherche disponible ne permet pas de trancher. Ces patterns décrivent ce que des praticiens ont vu fonctionner. L'article Critiques et état des preuves revient sur ce point et sur le marché des certifications.