1, 2, 3 ce sera toi le Scrum Master !

Que nous soyons adeptes de l’agilité sous chacune de ses formes, ou bien complètement newbee, nous avons pu faire face à des pratiques bien étranges lors de la mise en place d’équipes dites « agiles ». Parce que les frameworks connus, ou bien les adaptations que nous en faisons, ne définissent pas une méthode à suivre à la lettre mais plutôt une proposition de bonnes pratiques, certaines organisations d’équipes se cherchent, tâtonnent et parfois, se perdent.

L’identité d’équipe : pour quoi ?

Un exercice que j’affectionne quand je débute mon observation dans une mission d’accompagnement agile, que ce soit en tant que formatrice, scrum master ou facilitatrice, c’est de me faire une idée de l’identité de l’équipe. On se rend très vite compte de son existence ou non, en fonction de la cohésion observée, de l’entraide et de la légitimité qu’elle se donne aux yeux des autres équipes : forme-t-elle une unité bien précise et visible ? a-t-elle des habitudes qui lui sont propres - un café Teams tous les lundis matin ou des sucredises régulières ? Même nouvellement formée, une équipe en est une lorsqu’elle partage quelque chose de commun malgré les spécialités de chacun et les désaccords constructifs que l’on peut rencontrer.

J’ai eu la chance, dans une expérience récente, de participer à la création d’une nouvelle équipe, et c’est donc par là que j’ai commencé notre aventure commune : nous créer une identité. On se donne un nom (qu’on assumera !), on pousse parfois jusqu’à se choisir une mascotte ou une identité visuelle, on explique nos préférences, nos différences, le “qui aime faire quoi ?”, mais surtout, on se définit des valeurs communes : la qualité passera par les tests, on évitera d’utiliser tel outil pour nous faciliter la vie, on écoutera cette chanson à chaque bug en recette… et untel sera notre facilitateur.

Un facilitateur ? pas besoin !

Le besoin d’un facilitateur n’est pas toujours évident, mais il y a des situations qui parlent d’elles-mêmes : s’il s’agit d’une nouvelle équipe qui se rencontre pour la première fois et qui n’a jamais travaillé ensemble ; si l’équipe est composée de nouveaux venus dans l’informatique, sans connaissance de l’agilité, sans référence à un TechLead possible pour les orienter dans les bonnes pratiques de développement ; si l’équipe en place depuis longtemps et qui fonctionnait très bien jusque-là, fait face à des problématiques jamais rencontrées… La question d’avoir un facilitateur ou non prend tout son sens.

Mais même dans ces cas, j’ai vu le refus catégorique. « Il n’y a pas besoin de scrum master, un TechLead et une équipe ça suffit » dixit le coach. Alors d’accord, pourquoi pas, à condition que la situation dans l’équipe et tout autour de l’équipe le permette.

Ce sera toi TechLead !

Certains retours d’expériences m’ont montré que ça marche : d’abord le mien. Dans les équipes qui se connaissent et qui fonctionnent bien ensemble depuis un certain temps, le TechLead joue ce rôle de facilitateur à merveille : il est référent dans les bonnes pratiques de développements, de tests, il est souvent le peer-reviewer privilégié, il passe un certain temps à prendre de l’information en dehors de l’équipe… il a donc un rôle qui le prédestine à être le liant de l’équipe au besoin.

Ensuite, autour de moi, j’ai eu la chance de rencontrer et d’assister aux conférences de Baptiste Lecocq - Scrum est une fenêtre (ou bien un mur) - à Tours JUG 2019 et de Lise Quesnel – Lead Dev, 3 ans d’xp, et alors ? – à Jug SummerCamp 2021.

J’ai littéralement adoré la façon de faire de Baptiste dans son équipe en tant que TechLead : en mode routine, le rôle de facilitateur n’avait pas de grande utilité, et il était donc « absorbé » par chacun des membres de l’équipe, habitués aux process et interactions hors équipe de réalisation. Cependant, il se ré-attitrait ce rôle lors d’occasions bien précises comme l’arrivée d’un nouveau développeur par exemple. Tiens tiens… pour reconstruire l’identité d’équipe, ses valeurs, son “qui fait quoi et comment ?”, avant de revenir à la « routine ».

Un des points que je me suis notés de la conférence de Lise, c’est que sous l’étiquette de TechLead pouvait se cacher bien des rôles dont… celui de facilitateur, de coach et de formateur. Mais ce qui me reste en tête, c’est que tout le temps passé avec ces casquettes, à gérer les problématiques de l’équipes, à mettre en relation les bonnes personnes, à (re-)définir les bonnes pratiques et les axes d’améliorations, c’est autant de temps non passé sur le maintien de son expertise technique et de sa prise de recul sur les décisions techniques à prendre.

De ces retours, j’en tire un point de vigilance vital pour l’avenir des équipes sous ce mode de fonctionnement : la gestion du temps et des priorités en est affectée. Il me semble qu’il est donc nécessaire d’en avoir une certaine expérience pour ne pas se noyer ni devoir faire un choix cornélien entre deux casquettes différentes.

Un rôle tournant ?

J’ai rencontré plusieurs situations différentes qui ont fait naître le rôle tournant du facilitateur au sein d’une équipe.

La première situation était que, faute de scrum master dédié, personne ne voulait prendre ce rôle en charge, tout le monde trainait des pieds. Alors, un peu comme quand personne ne veut prendre en charge le support niveau 2 du suivi de production, on décide de faire tourner le rôle de Scrum Master. Spoiler alert : ça ne marche pas. C’est comme demander à un boulanger d’assurer 2 jours sur 6 la fabrication des pâtisseries de sa boulangerie. Assurer une nouvelle spécialité est tout à fait possible, à condition d’être volontaire et motivé. Sinon, vous finissez par vendre des pâtisseries déjà toutes faites !

La seconde situation fait apparaître une réelle envie de découvrir le rôle pour plusieurs personnes de l’équipe. Là, c’est différent : il y a de l’intérêt pour le rôle, et une envie d’apprendre. Cela peut marcher à condition de bien spécifier la priorité des rôles : si je suis à la fois développeuse back et Scrum Master pendant ma semaine d’itération, est-ce qu’on est d’accord que je privilégie ma casquette facilitante au service de l’équipe plutôt que la correction d’un bug de la semaine dernière ? Car oui, cette situation peut très souvent arriver et il faut rapidement statuer sur le comportement à suivre pour ne pas se perdre.

Et le Product Owner ? il connaît l’agilité !

Oui mais c’est une fausse bonne idée dans le temps. Rappelez-vous le Scrum Guide : « The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. » versus « The Scrum Master is a servant-leader for the Scrum Team ». Quand le premier est focalisé sur l’amélioration continue de son produit, le second veille à l’amélioration continue de l’équipe et de ses bonnes pratiques. Ce n’est pas toujours antinomique mais lorsque la décision de choisir entre donner encore plus pour le produit et protéger l’équipe des demandes inutilement pressantes, c’est toujours bien de pouvoir compter sur deux personnes différentes pour arriver à des compromis acceptables et pour l’équipe et pour le produit.

Quand le manager s’en mêle

Dans les entreprises dans lesquelles j’interviens et dans les formations que je donne, j’aime présenter le manager comme un facilitateur. S’il est rarement LE facilitateur interne à l’équipe, il est celui vers qui j’aime me tourner quand les axes d’améliorations identifiés prioritaires ne peuvent pas venir de l’équipe elle-même (l’auto-organisation c’est bien, mais tous les leviers ne se trouvent pas au travers des compétences de l’équipe). Quand les blocus se situent entre équipes qui ne se parlent pas ou plus, quand il est nécessaire de détendre les cordons de la bourse pour investir dans une solution ou une compétence, quand la connaissance historique de l’équipe est un atout : le manager est souvent la personne clé sur qui compter. J’ai d’ailleurs moi-même un rôle de formation et de coaching du manager dans cette aide apportée aux équipes.

Je n’ai, en revanche, jamais croisé le cas où le manager était le scrum master de l’équipe. Je serai très intéressée par des retours d’expériences dans cette situation. Si le Scrum Guide ne mentionne pas le manager, il ne l’efface pas pour autant. Mais je connais un autre cadre agile qui, par sa description précise de toutes les « cases » de l’entreprise dans son passage à l’agilité à l’échelle, efface littéralement le rôle de manager. Vous voyez duquel je parle ? Oui : SAFe.

Je me souviens d’avoir lu dans un rapport du Cigref de 2018 (*) que « La diffusion de l’agilité à l’échelle de l’entreprise est stimulée par […] le changement de positionnement du manager qui devient un leader-serviteur ». Tiens, tiens, exactement le rôle associé au scrum master dans le Scrum Guide (« The Scrum Master is a servant-leader for the Scrum Team. »).

Alors que penser d’un manager qui devient Coach Agile d’un train SAFe dans lequel se trouve l’équipe dont il reste manager sur le papier ? Pour moi, cela casse toute légitimité à le « former et coacher dans son rôle auprès des équipes ». Sa double casquette manager / coach de train, peut le positionner tantôt comme aidant, facilitant, guidant les équipes pour trouver leurs propres solutions, tantôt comme commanditaires ou juge.

Alors si je pouvais faire un souhait pour toutes les équipes de réalisations (de développement ou non), c’est que le manager devrait aider le scrum master de l’équipe, mais il ne peut devenir l’unique référent facilitateur de l’équipe, au risque de faire preuve d’injonctions contradictoires.

Alors, un scrum Master dédié ?

Au tout début de l’histoire d’une équipe, c’est préférable. On découvre les concepts, leurs intérêts, leur possible mise en place dans l’entreprise où l’on se trouve, on est peut-être même la première équipe fonctionnant en mode agile : il faut un agile team advocate qui saura rassurer l’équipe, lui donner une légitimité et la faire naviguer au sein de l’entreprise.

Par la suite, si l’entreprise prend goût à l’agilité, faire multiplier les équipes agiles peut passer par le « partage » d’un Scrum Master sur deux équipes, ou bien en faisant monter en compétence sur ce rôle un équipier de la première heure, pour passer à d’autres équipes à accompagner.

Dans tous les cas, parler aux équipes et prendre en compte leurs retours sur ce rôle est primordial. Et je vous le donne en mille : il existe un moment parfait pour échanger sur le sujet, qui a lieu régulièrement et qui a pour but de faire grandir l’équipe agile… Vous voyez ? la rétrospective !

* Cigref Agile at scale 2018

Article paru dans le numéro 252 de Programmez ! du 6 mai 2022