Voir la source de Le Team Leader doit-il être le Scrum Master

[[Category: Portail ScrumMaster]]
[[Category: Rôle du ScrumMaster]]
[[Category: Rôle du Team Leader]] 
Auteur : David Pereira<br />
Source : [https://www.goretro.ai/post/should-a-team-lead-be-scrum-master Should a Team Lead be the Scrum Master?]<br />
Date : 16/03/2023<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 14/01/2024<br />
----
Traduction :<br />
<br />
[[Fichier:Maitre-yoda-team-leader-ou-scrum-master.jpg|border|link=|800px]]<br/>
<br/>
Mon premier contact avec Scrum remonte à 2012. À l'époque, nous travaillions selon un [https://www.goretro.ai/post/agile-vs-waterfall-development-methodology#toc-5 modèle en cascade]. Les postes étaient bien définis : business analyst, ingénieur logiciel, ingénieur en assurance qualité, chef de projet, responsable de la livraison, et bien d'autres titres. Cependant, nos résultats ne cessaient de décevoir le nouveau directeur de l'exploitation ; il ne voyait pas de résultat justifiant les coûts globaux, et il souhaitait vivement que les choses changent. C'est à ce moment-là qu'une transformation massive s'est produite.<br/>
<br/>
Le directeur de l'exploitation a fait pression sur le directeur général pour qu'il modifie radicalement le département informatique. Ils ont proposé une approche radicale : mettre en œuvre Scrum et réduire la taille de l'équipe de moitié. Au début, j'ai été choqué. Je ne comprenais pas comment nous pourrions mieux fonctionner avec la moitié de nos effectifs. Pourtant, au bout de six mois, une chose est devenue évidente :

 Un petit nombre de personnes focalisées sur le résultat peut être plus performant qu'un grand nombre de personnes obéissant à des processus rigides.

La transformation ne s'est pas faite sans difficultés. Nous nous sommes heurtés à plusieurs reprises à des obstacles. L'un des défis auxquels nous avons été confrontés était de savoir qui devait assumer chaque rôle. Certaines choses étaient évidentes, par exemple, un Business Analyst devenant un Product Owner, mais nous avons eu du mal avec le [https://www.goretro.ai/post/scrum-master-roles-and-responsibilities rôle de Scrum Master]. Nous ne savions pas avec certitude [https://www.goretro.ai/post/who-should-lead-the-scrum-team qui devait guider l'équipe Scrum]. Nous avons essayé différentes approches jusqu'à ce que nous réussissions.<br/>
<br/>
Dans ce billet, je vais partager ce que j'ai appris des [https://www.goretro.ai/post/scrum-master Scrum Masters] en tant que Team Leader, membre de l'équipe ou personne neutre. J'espère que cela vous aidera à comprendre les avantages et les inconvénients de chaque scénario.

==Qu'est-ce qu'un Scrum Master ?==
Les entreprises interprètent souvent mal la signification de cette fonction. Si vous posez la question à dix personnes différentes, vous obtiendrez probablement dix réponses différentes. Avant de voir en quoi consiste ce rôle, il convient de comprendre ce qu'un Scrum Master n'est pas :
* Le secrétaire de l'équipe Scrum : responsable de la programmation de toutes les réunions et de tous les rituels nécessaires à l'équipe.
* Le thérapeute : celui qui est toujours là pour écouter les membres de l'équipe et leur proposer des séances de thérapie pour leurs problèmes.
* Le responsable de la livraison (Delivery Manager) : Il est chargé de maximiser la production de l'équipe et de convenir des dates de sortie.
* Le patron : il rencontre les membres de l'équipe [https://www.goretro.ai/post/one-on-one-meeting en tête-à-tête] pour micromanager ce qu'ils font et comment les pousser à faire davantage.

Une fois que vous aurez compris ce qu'un Scrum Master n'est pas, vous pourrez mieux comprendre le rôle à partir du [https://www.goretro.ai/post/scrum-beyond-scrum-guide Scrum Guide]. En gras, vous pouvez lire les aspects les plus pertinents :<br/>
<br/>
Le Scrum Master est responsable de la mise en œuvre de Scrum telle qu'elle est définie dans le Guide Scrum. Il le fait en aidant tout le monde à comprendre la théorie et la pratique de Scrum, à la fois au sein de l'équipe Scrum et au sein de l'organisation.<br/>
<br/>
Le Scrum Master est responsable de l'efficacité de l'équipe Scrum. Il le fait en permettant à l'équipe Scrum d'améliorer ses pratiques, au sein du cadre de travail de Scrum.<br/>
<br/>
Les Scrum Masters sont de véritables leaders au service de l'équipe Scrum et de l'organisation dans son ensemble.

==Le Team Leader en tant que Scrum Master==
Pour en revenir à ma première expérience avec Scrum, notre team leader était notre premier choix pour le poste de Scrum Master. Il se sentait responsable de notre succès en tant qu'équipe avec Scrum. L'expérience a eu deux aspects, positif et négatif. Laissez-moi vous expliquer ce que j'ai appris.

===Avantages===
Le Team Leader avait plus d'autorité sur l'organisation que n'importe quel autre membre de l'équipe, ce qui nous a beaucoup aidés au cours des premières phases de notre mise en œuvre. Voici quelques points clés :
* '''Accès''' : notre Team Leader a participé à plusieurs réunions avec des dirigeants auxquelles aucun autre membre de l'équipe n'avait accès. Cela lui a permis de plaider en faveur de différentes méthodes de travail et de collaboration. Il a profité de toutes les occasions pour expliquer aux parties prenantes de haut niveau comment tirer profit de Scrum.
* '''Autorité''' : étant donné qu'il était un développeur expérimenté promu Team Leader, l'organisation a respecté son point de vue et l'a suivi. Les managers lui faisaient confiance, indépendamment de Scrum, et l'écoutaient donc au lieu de rejeter ses arguments.
* '''Adoption rapide par l'équipe''' : les membres de l'équipe n'aiment pas contrarier leur chef. Nous avons rencontré peu ou pas de résistance à l'adoption de Scrum au sein de l'équipe. Tout le monde était d'accord pour essayer et participait à tous les événements avec un esprit ouvert. J'attribue cela au fait que le responsable direct a insisté sur ce point et que personne n'a voulu aller à son encontre.

===Inconvénients===
Le Scrum Master est venu s'ajouter aux responsabilités de notre Team Leader, ce qui a parfois fonctionné, mais a aussi causé des conflits à plusieurs reprises. Voici quelques exemples :
* '''Disponibilité''' : nous devions constamment décaler nos [https://www.goretro.ai/glossary/scrum-events événements Scrum] en raison de conflits d'agenda. C'était ennuyeux et démotivant.
* '''Conflit d'intérêt''' : le Team Leader ne pouvait pas adopter une position neutre dans de nombreuses situations. Par exemple, un développeur prenait plus de temps que prévu pour terminer une tâche. Le Team Leader interrompait le développeur au quotidien et demandait une explication au lieu d'évoquer la situation et de laisser l'équipe trouver une solution.
* '''Agenda secret''' : à un moment donné, nos mêlées sont devenues fatigantes car notre Team Leader abordait fréquemment des sujets inattendus, des annonces ou autre chose. En bref, au lieu de 15 minutes, nous avions tendance à prendre 25 à 30 minutes par jour. Cela démotivait l'équipe, et personne ne disait rien par crainte d'un conflit avec le chef.
* '''Presser le citron''' : de temps en temps, le Team Leader prenait une position de manager et demandait à quelqu'un de l'équipe de faire quelque chose pour lui. Indépendamment de [https://www.goretro.ai/post/sprint-goals-crafting l'objectif du sprint] et de nos progrès, le Team Leader oublie tout ce qui concerne Scrum et interrompt l'équipe.

La chose la plus dangereuse lorsqu'un Team Leader porte la casquette de Scrum Master, c'est la responsabilité du management des personnes. Il est difficile d'adopter une position neutre et l'équipe ne deviendra pas plus forte si elle craint les conflits.

==Un membre de l'équipe en tant que Scrum Master==
Au bout de trois mois, notre Team Leader s'est rendu compte qu'il nuisait à l'équipe en tant que Scrum Master et a demandé à se désister. C'était une action noble de sa part, telle qu'il la percevait lui-même. Nous n'avions pas de solution, mais il nous a demandé de réfléchir à la manière dont nous voulions procéder. Notre choix s'est porté sur un membre de l'équipe pour prendre le rôle de Scrum Master.<br/>
<br/>
L'ingénieur QA a décidé de porter la casquette de Scrum Master. Cette configuration s'est poursuivie pendant trois mois, et voici ce que j'ai appris :

===Avantages===
C'est l'équipe qui a le plus bénéficié du fait qu'un membre de l'équipe agisse en tant que Scrum Master. Voici quelques avantages :
* '''Cadence''' : nos événements ont atteint une fréquence normale. Chaque événement se produisait au même moment et au même endroit. Cela a réduit les frictions et nous avons appris à [https://www.goretro.ai/post/timeboxed-events-in-scrum cadencer] nos échanges.
* '''Conflit''' : le Scrum Master pouvait nommer les conflits avec l'équipe et encourager l'équipe à les résoudre tout en faisant partie de l'équipe. J'ai eu l'impression que nous avons grandi en tant qu'équipe car nous pouvions mettre le doigt sur ce qui ne fonctionnait pas bien.
* '''Équilibre''' : en tant que membre de l'équipe, le Scrum Master nous a permis de ne pas être interrompus. Le Product Owner ne pouvait pas ajouter de sujets supplémentaires au Sprint, et les parties prenantes étaient redirigées vers le Product Owner chaque fois qu'elles voulaient quelque chose de plus.

===Inconvénients===
Comme dans notre scénario précédent, les responsabilités d'un Scrum Master sont venues s'ajouter aux responsabilités actuelles de notre QA. Cela n'a pas facilité son épanouissement dans ce rôle supplémentaire. Nous avons eu des difficultés avec les éléments suivants :
* '''Les rétrospectives mécaniques''' : presque toutes les rétrospectives avaient le même format ; nous répondions mécaniquement aux mêmes questions. De plus, nous ne suivions pas les actions convenues pendant le Sprint, et petit à petit, la rétrospective a perdu de sa valeur, et nous avons commencé à la zapper.
* '''Un Scrum Master absent''' : lorsque nous avions le plus besoin du Scrum Master, il était absent parce qu'il devait porter sa casquette de QA. Par exemple, nos affinages sont devenus chaotiques et stressants, le Product Owner voulait parler de problèmes à résoudre, et les développeurs voulaient des exigences précises à mettre en œuvre. La discussion tombait souvent dans une spirale technique et nous ne pouvions plus avancer. Le Scrum Master était absent parce qu'il participait également à la discussion.
* '''Faible implication du top management''' : notre QA n'avait aucune interaction avec les cadres et les dirigeants, et ces derniers rejetaient ses invitations à des réunions. Lentement, l'adoption de Scrum s'est détériorée parce que les parties prenantes influentes sont revenues à leur comportement antérieur de contrôle-commande.

Le changement de responsabilités était considérable, et notre QA n'avait qu'un succès mitigé dans ces rôles. Au bout de trois mois, il a souhaité se concentrer soit sur le QA soit sur le Scrum Master. Ce qui m'amène à la dernière variation que nous avons expérimentée.

==Une personne neutre en tant que Scrum Master==
Nous étions sceptiques quant à nos progrès. En tant qu'équipe, nous nous sentions plus forts, mais la pression exercée par nos parties prenantes était insupportable. Nous avions besoin d'aide. De nombreuses parties prenantes exigeaient la prédictibilité et voulaient interrompre nos [https://www.goretro.ai/glossary/what-are-sprints sprints] en permanence. Ils ont ignoré le fait que nous travaillions avec Scrum et ont commencé à se montrer agressifs : "Je me fiche de la façon dont vous travaillez, je veux que ce soit fait pour demain !"<br/>
<br/>
L'entreprise a décidé de faire appel à un consultant externe pour agir en tant que Scrum Master. Nous étions novices en matière de Scrum, cela ne faisait que neuf mois que nous avions organisé notre premier Sprint, et nous espérions qu'un Scrum Master expérimenté était tout ce dont nous avions besoin.<br/>

===Avantages===
Nous avons rapidement observé plusieurs avantages à avoir une personne expérimentée comme Scrum Master, et nos progrès se sont accélérés. Voici quelques-uns des changements fondamentaux :
* '''Rétrospective sur mesure''' : des échanges mécaniques aux échanges engageants, c'est ce qui s'est passé avec nos rétros. Notre Scrum Master savait comment apporter le format approprié pour découvrir nos goulets d'étranglement, Sprint après Sprint ; j'ai senti que nous sommes devenus une équipe plus forte.
* '''Davantage de questions et moins de réponses''' : je ne me souviens pas que notre Scrum Master nous ait donné des réponses à nos problèmes, mais je me souviens qu'il nous a posé beaucoup de questions. J'avais l'impression qu'il nous donnait toujours une longueur d'avance et qu'il nous aidait à avancer pas à pas. C'est comme s'il savait à quelle question nous devions répondre.
* '''Transparence''' : il savait comment s'y prendre avec les parties prenantes qui se montraient insistantes. Il les invitait à prendre un café, partageait ses observations et les aidait à comprendre les effets sur notre équipe. Ensuite, il expliquait comment une [https://www.goretro.ai/glossary/team-collaboration collaboration] durable pouvait être bénéfique.
* '''Des mots justes''' : il était direct et savait comment s'y prendre avec des parties prenantes exigeantes. Je me souviens d'une fois où il a fait venir une partie prenante dans un coin de la pièce et lui a dit : "Si vous les poussez à fournir plus sans les engager, vous n'obtiendrez rien d'autre que de la résistance. En revanche, si vous leur donnez une raison d'être et leur demandez de vous aider à atteindre les objectifs, vous bénéficierez d'un engagement. C'est à vous de choisir." Cela a changé la donne pour nous.

===Inconvénients===
Au début de notre relation avec notre nouveau Scrum Master, je ne voyais aucun aspect négatif. Pourtant, au fur et à mesure que notre équipe grandissait, j'ai remarqué que notre collaboration changeait. Voici quelques caractéristiques :
* '''Silence''' : le Scrum Master était silencieux et échangeait à peine avec nous. Il semblait étranger à notre équipe. Il restait silencieux sur sa chaise et je me sentais loin de lui. Même s'il était là pour nous, je n'avais pas l'impression qu'il était avec nous pendant nos sprints.
* '''Seules les questions ennuient l'équipe''' : compte tenu de nos progrès, il était rare que nous soyons confrontés à un problème en tant qu'équipe et que nous demandions de l'aide au Scrum Master. Mais lorsque nous avions besoin d'indications, il ne posait que des questions et nous avions l'impression qu'il ne nous rejoignait pas là où nous avions besoin de lui.
* '''Résultat incertain''' : au fur et à mesure que nous devenions autonomes, nous nous impliquions de moins en moins avec le Scrum Master. Nous avons commencé à douter de la valeur de son travail avec nous parce que la plupart du temps, il n'avait des interactions que lors de nos événements Scrum.

==Mon point de vue==
Depuis cette expérience, j'ai fait partie de dizaines d'équipes Scrum, forgeant mon point de vue en fonction de chaque scénario. Le meilleur choix dépend fortement de votre scénario. Mon approche est la suivante :
* '''Équipe et organisation inexpérimentées''' : un Scrum Master dévoué et compétent est essentiel au succès. De préférence, cette personne ne fait pas partie de l'équipe et n'a aucun pouvoir décisionnel sur les membres de l'équipe.
* '''Équipe et organisation expérimentées''' : un membre de l'équipe peut jouer le rôle de Scrum Master dans un scénario où l'équipe fonctionne de manière autonome. Il est préférable d'avoir une responsabilité de Scrum Master tournante pour les membres de l'équipe.

Pour répondre à ma question initiale, un Team Leader doit-il être le Scrum Master ? Je suis contre, car cela empêcherait les membres de l'équipe d'avoir des conflits récurrents et d'évoluer en tant qu'équipe. De plus, le Scrum Master fonctionnerait mieux sans aucune activité au sein de l'équipe ; cela lui permettrait d'agir en tant qu'observateur et d'aider l'équipe à progresser pas à pas.

 '''"Scrum est comme votre belle-mère, il pointe du doigt TOUTES vos fautes."'''  - Ken Schwaber

Cf. [[Scrum est comme votre belle-mère]]