Le Scrum Master est une des personnes les plus importantes pour une transformation Agile en Scrum réussie. Or son rôle est souvent mal compris ou interprété différemment au sein des équipes et des organisations, et c’est régulièrement l’objet de difficultés.
Un réflexe régulier dans une entreprise est de ”recycler” une partie des chefs de projets (CP) en Scrum Master (SM). Ce n’est pas impossible, c’est même souvent plutôt logique, il y a pleins de points communs. Mais il est important de comprendre qu’un SM n’est surtout pas un CP. Il agit en tant que catalyseur du processus Scrum. Cependant il n’est pas le responsable de l’équipe. Il joue un rôle clé dans la mise en œuvre efficace des principes et des pratiques de cette méthodologie. Il élimine les obstacles, encourage la collaboration et l'autonomie au sein de l'équipe.
Une autre approche que j'ai personnellement vécue, consiste à attribuer le rôle du Scrum Master aux Tech Leads (TL) déjà présents au sein des équipes. En effet, certaines tâches de ce rôle semblent similaires à celles du Scrum Master. Cependant, même si ces deux rôles partagent des similitudes et que souvent des développeurs seniors deviennent Scrum Master, les compétences et les qualités nécessaires sont fondamentalement différentes.
Lors de cet article, je vous partagerai mon retour d’expérience d'être à la fois Scrum Master et Tech Lead sur plusieurs squads. Je vous ferai part des enjeux, des risques, des limites et des problèmes de cette solution.
Tout d’abord il faut définir ce qu’est un Tech Lead.
Il est important de préciser que ce rôle n’existe pas dans le Scrum Guide. Cependant le cadre de travail décrit dans le Scrum Guide est volontairement incomplet. Il n’y a pas non plus de description des postes de Business Analyste, d’Architecte, de Testeur Agile ou de Devops pourtant plein d’équipes ont ces postes.
Le TL à généralement dans les attributions de son rôle :
- Pousser à l'excellence technique et promouvoir les bonnes pratiques
- Suivre et limiter la dette technique
- Animer la prise de décision des choix techniques
- Organiser la revue de code et le pair programming
- Accompagner les moins sachants
- S’assurer de la cohérence technique du produit et avec le reste du SI
- Cultiver le lien avec les autres TL et Architectes de l’entreprise
- Connaître la chaîne d’intégration continue
Un bon TL, c’est généralement un dev sénior qui a du recul. Les qualités attendues sont donc avant tout technique. Il est important de savoir écouter, promouvoir des bonnes pratiques, prendre des décisions et de savoir communiquer efficacement.
Et donc un Scrum Master c’est quoi ?
Ce rôle est unique à Scrum. Pour cette raison, il est souvent associé par erreur à des responsabilités déjà existantes dans les organisations. Il faut donc souvent commencer par expliquer que Scrum Master ce n’est pas :
- le “nouveau” chef de projet
- Le responsable technique
- Le manager de l’équipe
- La personne qui “fait les reporting”
En revanche le rôle de Scrum Master est d'être :
- Garant de la mise en place du Scrum et des rituels
- Facilitateur et de limiter les obstacles
- Formateur à l’agilité
Son rôle est de s’assurer que l’équipe fournisse un produit de la meilleure qualité possible. Il répond à une logique d’amélioration continue et non de résultat. A la différence du TL, son rôle est beaucoup plus d’animer une équipe et de la laisser expérimenter que de prendre des décisions.
Il n’y a plus de chef de projet
Une des plus grosses difficultés de la mise en place de Scrum, c’est que cela fonctionne sans CP. Cela peut être très perturbant quand on a d’autres habitudes. Quand on présente Scrum une question qui revient souvent est “Il est où le chef de projet ?”
Dans Scrum, les responsabilités et le leadership sont répartis plutôt que concentrés entre les mains d'une personne unique. L'absence de chef de projet traditionnel vise à favoriser l'autonomie de l'équipe, la collaboration et la responsabilisation de chacun des membres de l’équipe pour atteindre les objectifs fixés.
Une des tentations lors d’une transformation Agile est de concentrer certaines responsabilités dans les équipes ce qui risque de “recréer” volontairement ou non un CP. C’est pour moi l’une des raisons qui font que l’on voit fleurir sur internet des intitulés de poste ou des offres d'emplois du type “Chef de projet Agile” ou “Scrum Master / Tech Lead”
Quels sont les risques de porter les deux casquettes
Il est important de comprendre quels sont les risques d’être Tech Lead et Scrum Master, car quand on les connaît c’est plus facile de les éviter.
Le premier c’est de dévoyer le Scrum et devenir un chef de projet technique. Le risque est d’autant plus présent si l’entreprise n’est pas habituée au Scrum. C’est la première difficulté à laquelle j’ai dû faire face. Car d’une part, le management risque de penser votre poste comme celui d’un CP et de s’adresser à vous et à l’équipe comme si vous l'étiez. D’autre part, en cumulant un rôle de leader technique et leader organisationnel, la Scrum team risque de devenir attentiste à vos décisions. Or c’est l’un des points les plus importants du Scrum Guide “Les équipes sont autogérées, elles décident en interne qui fait quoi, quand et comment.” On peut malheureusement rapidement dévoyer les principes du Scrum, trop centraliser les décisions, perdre le recul nécessaire, et donner une mauvaise image du Scrum en détournant ses principes.
Le second risque auquel j’ai dû faire face, c’est de devenir la Scrum Mom de l’équipe. C'est-à-dire la personne qui la surprotège, qui filtre les commentaires des parties prenantes et du management. Qui s'occupe personnellement de tous les obstacles, même si pratiquement n'importe quel autre membre de l'équipe pourrait également agir. Le risque est de laisser l’équipe dans sa bulle confortable et de la déconnecter des réalités de l’environnement auquel elle est connectée. Ce risque est déjà présent sans cumuler les rôles mais je trouve qu’il est encore plus présent du fait du cumul. De plus vous risquez d'être le point d’entrée de l’équipe vers l’extérieur, il est donc important de ne pas isoler l'équipe. J’ajouterai que votre double rôle ne vous aide pas à prendre du recul, ce n’est donc pas simple de combattre la Scrum Mom qui sommeille en vous.
Un autre risque auquel j’ai été confronté, c’est de mettre une barrière entre le PO et les autres membres de l’équipe. En effet, vous devenez l’interlocuteur privilégié du PO dans l’équipe. Car le PO aura besoin de votre expertise dans les 2 rôles avec comme conséquence possible de moins échanger avec le reste de l’équipe. La même barrière peut également se créer entre le TL/SM, le PO d’un côté et le reste de l’équipe de l’autre.
Le dernier point que j’ai noté, est la difficulté de concilier les postures à avoir dans ces deux rôles. Car un Scrum Master doit animer une équipe, l'accompagner à identifier des problèmes et l’amener à les résoudre par elle-même. Son but est de rendre autonome, il doit donc amener les gens à prendre des décisions et non les prendre lui même. Au contraire, le TL est plus dans rôle où il doit prendre des décisions. Assurer les deux rôles revient donc souvent à concilier l'inconciliable en étant juge et partie.
Comment limiter/résoudre ces risques ?
Pour éviter les risques de cette double casquette j’ai pu trouver quelques astuces pour mieux gérer la situation.
Tout d’abord, faire parler les autres avant soi, et s’obliger à moins parler. En effet, si sur un sujet le TL/SM parle en premier, c’est plus difficile de faire participer tout le monde et que chacun donne son avis. C’est pour cela que le plus possible sur des sujets techniques ou d’organisation je prenais la parole en dernier voir même pas du tout. Si tout le monde tombe d’accord sur une solution, pas besoin d’intervenir. Cela permet de garder la neutralité du Scrum Master sans trop gêner le Tech Lead qui dans ces cas là est plus participatif que directif, mais cela peut avoir du bon.
Ensuite, faire animer dès que possible par les autres, les rituels de l’équipe. Pour cela il faut trouver des volontaires si possible tournant. Cela favorise la montée en compétence de l’équipe dans son auto-organisation, et l’auto-implication. Cela permet également de se décharger plus facilement quand on n’est pas disponible ou en vacances. Une solution peut être de faire monter en compétences une personne de l’équipe. D’une part pour servir de relais sur des sujets ou d’autre part pour vous remplacer petit à petit sur un des deux rôles.
Une autre bonne astuce, c’est de faire voter les décisions d’équipe. Un point important c’est que le vote du TL/SM n’a pas plus de valeur qu’un autre. Le fait qu’il se plie à la décision majoritaire sans être lui-même majoritaire permet de montrer à tout le monde que le TL/SM n’est pas au-dessus de l’équipe. J’ai déjà pu constater avec plusieurs exemples que cela décuple l’auto-organisation, l'engagement, l’implication et la responsabilisation de chacun.
Conclusion
Etre en même temps Scrum Master et Tech Lead n’est pas l’idéal. Même si assurer les deux rôles est possible, il est important de comprendre qu’ils sont difficilement conciliables. Un Tech Lead et un Scrum Master ont besoin de qualités et postures différentes. Il faut donc quand c’est possible séparer les deux.
Si vous assurez les deux rôles, il vous faudra beaucoup de soft skills pour éviter les embûches, savoir vous entourer et faire monter en compétences chacun. Coacher votre équipe sur l’agilité sera primordial pour vous éviter de prendre de mauvaises habitudes. Vous pouvez à moyen terme, faire monter en compétence des personnes pour vous remplacer sur un des deux rôles. Ainsi vous re-séparez les deux rôles dans votre équipe.
