Le Team Leader doit-il être le Scrum Master
Auteur : David Pereira
Source : Should a Team Lead be the Scrum Master?
Date : 16/03/2023
Traducteur : Fabrice Aimetti
Date : 14/01/2024
Traduction :
Mon premier contact avec Scrum remonte à 2012. À l'époque, nous travaillions selon un 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.
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 rôle de Scrum Master. Nous ne savions pas avec certitude qui devait guider l'équipe Scrum. Nous avons essayé différentes approches jusqu'à ce que nous réussissions.
Dans ce billet, je vais partager ce que j'ai appris des 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 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 Scrum Guide. En gras, vous pouvez lire les aspects les plus pertinents :
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.
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.
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 é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 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.
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 à 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.