Être Scrum Master… mais à distance

Cela fait un petit moment que je souhaitais partager mon expérience à propos d’une mission atypique qui m’a beaucoup appris en 5 ans.

Scrum (la Mêlée en français) définit un cadre de travail pour des équipes ayant pour mission de livrer une solution logicielle adaptée à un utilisateur final placé au centre des préoccupations. Telle une mêlée de rugby, tous les membres d’une équipe doivent pousser ensemble dans la même direction pour pouvoir avancer et atteindre un objectif commun. La communication au sein du groupe doit être fluide et rapide. La proximité et les interactions physiques font partie intégrante des principes Agiles. Au sein de cette équipe, le Scrum Master est en quelque sorte le demi de mêlée et son rôle est de fluidifier le travail des autres en les laissant se focaliser sur l’essentiel : faire avancer la mêlée. On le qualifie souvent de “facilitateur” ; il doit s’assurer que l’information circule bien et de manière transparente.

Toujours en restant sur cette métaphore rugbystique, comment imaginer un match alors que le demi de mêlée ne joue même pas sur le même terrain ? C’est exactement ce qui m’a été demandé de mettre en place en tant que Scrum Master d’une équipe localisée à près de 2000 km de moi, en Bulgarie. Cet article a pour but de vous faire partager mon expérience, les problématiques auxquelles j’ai été confronté et comment je m’en suis sorti.

Contexte de la mission

J’ai commencé ma mission dans une entreprise française dans un contexte juridique contraignant. La solution informatique était développée par des équipes à Sofia, en Bulgarie, et représentait une référence importante en Europe. Après deux ans, l’entreprise française a été rachetée par une société américaine dont la partie technique était principalement réalisée en Inde. Les américains ont ensuite été rachetés par des Allemands. Au final et avec les différents rachats, je me suis retrouvé avec des développeurs en Bulgarie, des architectes à Bangalore, des Product Owners au Pérou et le tout en rendant des comptes à des Américains et à des Français. L’une de mes plus grandes craintes avant de commencer cette mission était mon anglais qui était très scolaire et manquait cruellement de fluidité. J’ai vite rattrapé mon retard et je suis maintenant capable de survivre à des réunions en anglais avec des accents très différents et un son pas toujours de qualité. En tout, pas moins de 14 équipes Scrum travaillaient sur des évolutions de la plateforme américaine.

Maintenant que le décor est planté, concentrons-nous sur ma vie de Scrum Master aux interlocuteurs distants.

Faire partie de l’équipe sans être là

Difficile de se sentir comme membre à part entière d’une équipe composée de personnes qui se connaissent bien, que vous n’avez jamais rencontrées et qui ne parlent pas nativement la même langue que vous. J’ai eu l’occasion de côtoyer et d’apprendre à connaître les développeurs et les testeurs en passant une semaine tous les trois mois à Sofia. Cette fréquence s’est imposée d’elle-même car elle correspondait bien à l’équilibre entre contraintes budgétaires et besoin de discuter en face à face avec mon équipe. Le contact humain est essentiel pour l’esprit et la cohésion d’équipe. Je ne pense pas que je m’en serais sorti sans ces voyages qui m’ont clairement permis d’humaniser la communication avec mon équipe. L’accueil des Bulgares à mon égard a toujours été irréprochable et je garde d’excellents souvenirs de mes soirées passées là-bas !

Un Scrum Master doit être à l’écoute de son équipe et pas uniquement dans le cadre d’une discussion entre lui et l’équipe. Il doit réussir à capter les zones de tensions, les irritants et tout ce qui peut ralentir la productivité de l’équipe. Bien souvent, ces informations ne sont pas accessibles par des échanges formels et, sans une présence quotidienne, il est bien difficile d’identifier les axes d’amélioration. Selon moi, le Scrum Master doit être “vu” par l’ensemble de l’équipe comme une ressource clé qui est là pour améliorer les conditions de travail et contribuer au bien-être des membres de son équipe. Il n’est pas le chef de l’équipe car c’est l’équipe elle-même qui définit la marche à suivre selon les contraintes de l’entreprise. Cette absence de hiérarchie fait du Scrum Master un membre à part entière de l’équipe. Il doit être accessible humainement et toujours disponible.

Se pose ensuite l'éternelle question de savoir si le Scrum Master doit développer ou non. Selon moi, il peut mais doit avoir pour priorité de s’occuper de l’équipe. Si le demi de mêlée considère qu’il est préférable de pousser avec ses camarades de jeu, il est probable qu’il n’arrive plus à se concentrer suffisamment sur la récupération et le dégagement de la balle qui est bien plus importante pour marquer des points. Pour ma part, je ne développais pas mais je suivais de près ce que l’équipe de développement produisait pour rester sur le terrain et être au cœur de la partie. Les revues de code étaient réalisées en ligne, via Crucible, et pouvaient faire intervenir plusieurs Indiens selon les fichiers modifiés et les ACL correspondants. C’était un passage obligatoire pour permettre aux développeurs bulgares de pousser leur code. Le plus important pour moi était de gagner le respect de l’équipe en me montrant utile au quotidien. Ce dernier point a été un défi plus difficile à relever que le simple fait d’améliorer mon anglais.

Communiquer

Quel que soit le moyen choisi, un Scrum Master à distance ne peut exister qu’au travers d’une communication régulière et bienveillante. Tous les entraîneurs vous le diront, il faut communiquer pour avancer ! La manière de parler dépend beaucoup des individus. Personnellement, j’utilise beaucoup l’humour pour faire passer mes messages. Il faut néanmoins faire très attention à son niveau d’anglais et à la culture de son interlocuteur car une petite boutade pour détendre l’atmosphère peut vite se transformer en malaise en cas d’incompréhension. J’ai personnellement vécu ce genre de moment gênant avec des Indiens qui sentaient leur intelligence insultée quand je leur demandais d’oublier une petite blague incomprise (ou tout simplement pas drôle). Depuis ce jour, je n’ai plus tenté de jeu de mot acrobatique, ou alors uniquement avec les Bulgares.

Il existe plusieurs canaux de communication qui présentent chacun des avantages et des inconvénients.

Le téléphone est un moyen rapide de faire passer un message et de vérifier que la personne a bien compris. Il a également l’avantage de fournir des informations directes quant à l’humeur et la motivation de l’interlocuteur. Son principal inconvénient est de monopoliser l’attention de quelqu’un à un moment qui peut ne pas être opportun et de faire parler un membre de l’équipe à haute voix au milieu d’un open space. En tant qu’ancien développeur, je sais qu’il peut être très désagréable voire contre-productif d’être coupé en pleine folie créatrice. D’un autre côté, c’est parfois le meilleur moyen de transmettre une information urgente et de s’assurer qu’elle est comprise et bien prise en compte. Tout n’est qu’une question de dosage. Le mieux reste de réserver un créneau horaire pour planifier un appel sur un sujet précis si l’urgence le permet. La vidéoconférence est une option que je n’ai que très rarement utilisée car je considère qu’elle n’apporte pas grand-chose de plus, à part pour un premier contact.

L’écrit est moins intrusif et permet de conserver des traces des informations échangées. Il permet également de pallier les éventuelles incompréhensions liées à un vocabulaire anglais incomplet, que ce soit pour l’émission du message ou à sa réception. À mes débuts et par manque de confiance en moi, j’ai beaucoup utilisé les outils comme Skype ou l’envoi d’e-mail pour échanger avec les membres de mon équipe. Il m’est même arrivé de tchatter avec des collègues bulgares alors que j’étais juste à côté d’eux.

Choisir le média le plus approprié est important mais bien moins que le contenu des échanges. Les Bulgares sont généralement très respectueux de la hiérarchie et me considéraient comme leur supérieur ce qui bridait quelque peu la spontanéité et les messages non formels. L’humour m’a beaucoup aidé à fluidifier les échanges et à montrer à l’équipe que j’étais de leur côté.

Déceler les problèmes et mener des actions correctives est l’une des missions d’un Scrum Master. Même à distance, il est possible de ressentir les frustrations et de mesurer la motivation d’une équipe. Il faut être très attentif à tous les échanges, à la voix, aux champs lexicaux (bien que limités par l’anglais) ou même encore les émoticônes utilisés. En général, j’arrivais à repérer les problèmes humains en amont et je profitais de mes voyages sur place pour tenter de les solutionner. Une semaine était amplement suffisante car ces points étaient ma priorité. Je découvrais souvent que la situation était pire que ce que j’avais interprété. Avec le temps, je me suis beaucoup plus méfié de ces petits détails pouvant cacher de sérieux problèmes qu’il faut traiter rapidement.

La communication tacite

Au cours du développement d’une application informatique, de nombreuses données sont créées, représentant une source importante de communication. Il est tout à fait possible de suivre l’avancée d’un sprint au cours d’une journée uniquement en se basant sur les changements de statuts et les commentaires des tickets. La seule contrainte est que tout le monde modifie bien ses tickets à chacune des phases de développement ou de test. J’ai longtemps bataillé sur ce sujet et mon principal ennemi était les post-its que l’équipe collait un peu partout. Après qu’ils aient compris qu’il était plus rapide de déplacer un ticket dans JIRA que de répondre à leur Scrum Master par rapport à une question sur l’avancement d’un développement, tout le monde s’y est mis. Le management visuel est généralement très utile mais isole complètement les personnes n’y ayant pas accès. Avec des outils bien configurés et de bonnes habitudes de travail, nous avons réussi à nous en passer sans difficulté.

Organiser les rituels

Le Scrum Master est souvent assimilé à la personne animant les cérémonies Agiles. Ces dernières étant généralement basées sur des échanges oraux, ne pas avoir tout le monde dans la même pièce peut s’avérer problématique. L’un des socles des méthodes Agiles est l’amélioration continue et la possible remise en question de procédures qui peuvent ne pas être adaptées à un contexte particulier. Si un rituel est inefficace et constitue une perte de temps, il faut l’adapter.

La mêlée quotidienne

Chaque journée de travail commençait donc par la mêlée qui était téléphonique. J’étais réticent au début mais elle est vite devenue très importante pour moi car elle me permettait de saluer l’équipe de vive voix, de leur rappeler que j’étais là et que je partageais les mêmes problématiques qu’eux. Mieux, j’étais là pour les régler et que le fait de s’ouvrir à moi leur permettait de se débarrasser de problèmes d’organisation et de communication avec des équipes un peu partout sur le globe. Toute l’équipe a fini par adhérer à ce rituel et à en comprendre l’intérêt. À la différence d’une mêlée plus conventionnelle où chacun sait quand il doit parler, il faut explicitement désigner la prochaine personne devant s’exprimer. Je m’arrangeais toujours pour ne jamais suivre le même ordre afin de conserver l’attention de tous. Il faut bien prendre en compte que dans ce genre de réunions, tout le monde coupe son micro et peut faire à peu près ce qu’il veut donc mieux vaut être prévoyant. Avant de commencer, j’avais pour habitude de faire quelques vocalises pour avoir une voix “réveillée”. L’échauffement est très important avant de commencer un match !

Le Sprint planning

Le contexte du projet était particulier car les équipes ne travaillaient pas sur un backlog global mais par fonctionnalités importantes. Ces dernières étaient décrites dans une spécification très complète écrite par les PO péruviens. En général, on pouvait prendre entre un et trois sujets selon des estimations de complexité réalisées par les architectes américains (au doigt levé nous semblait-il). Le découpage en récits fonctionnels était à la charge des équipes de développement qui choisissaient la maille la plus adaptée. Il fallait en général plusieurs réunions de présentation puis de questions / réponses pour estimer si oui ou non l’équipe était en mesure de traiter l’ensemble de la fonctionnalité au sein d’un sprint. L’équipe était composée de Quality Analysts (1 pour 2 développeurs) qui avaient pour mission de valider la bonne couverture fonctionnelle en tests automatisés. Ces personnes participaient activement à la phase de clarification du besoin. Le Tech Lead de l’équipe avait pour mission de fournir une spécification technique quant aux changements nécessaires pour l’implémentation de la fonctionnalité. Les spécifications fonctionnelles et techniques doivent impérativement être approuvées et signées par l’architecte de la solution, une sorte de grand gourou extrêmement sollicité. Le plan de test était également soumis à l’approbation des “QA Managers”. On était bien loin d’un contexte Agile sur ce point mais c’était la procédure à suivre car elle correspondait plus au contexte légal empêchant les livraisons partielles d’une fonctionnalité.

Mon rôle dans tout ça était de :

• planifier ces réunions ;
• clarifier le besoin au maximum ;
• proposer des maquettes aux équipes UX ;
• obtenir les validations pour respecter une Definition Of Ready très procédurale.

J’avais pour habitude de dessiner chaque spécification sur une même page. C'était un exercice ardu mais très instructif car il permettait d’identifier les manques fonctionnels et servait de support pour la création des plans de tests des QA. Les fonctionnalités attendues correspondaient généralement à des portages de ce qui existait sur la solution française vers la plateforme américaine, ce qui m’a permis d’utiliser mes connaissances fonctionnelles sur le sujet. Avec les 14 équipes Scrum et des fuseaux horaires entre l’Inde et la côte ouest américaine, la phase de préparation pouvait durer plusieurs semaines. Toutes ces réunions devaient être préparées à l’avance afin de rendre le plus efficace possible ces moments d’échanges. J’avais pour habitude de vérifier mes e-mails avant d’aller me coucher au cas où les questions posées par l’équipe avaient reçu des questions en guise de réponse. Ne pas clarifier ces points dans la soirée revient à reporter au lendemain soir l’explication du PO qui ne répondra pas nécessairement dans la soirée. En tout, il est très simple de rester deux jours (voire plus) avec une question en suspens si les interlocuteurs bottent en touche !

La Rétro

Les rétrospectives étaient la plupart du temps planifiées les semaines où j’étais à Sofia et ne correspondaient pas systématiquement à une fin de sprint qui durait un mois. Pour celles réalisées à distance, j’ai dû improviser une solution. L’idée était d’avoir un support PowerPoint partagé via WebEx. Après avoir présenté le scénario, chaque membre de l’équipe devait me transmettre par Skype les points positifs et les points négatifs. De mon côté, j’avais préparé l’équivalent de post-its sur un outil de dessin (yEd) et il ne me restait plus qu’à coller le contenu du message et le nom du membre de l’équipe dedans.

Comme tous les retours n’arrivent jamais en même temps, j’avais le temps d’avoir un document contenant tous les tickets. Je devais néanmoins faire vite pour ne pas casser la dynamique de la réunion. La création des tickets était faite sur un écran non partagée au reste de l’équipe. Une fois tous les retours informatisés, je présentais une page blanche à l’équipe et je copiais-collais les tickets un par un. Son auteur ajoutait alors un petit commentaire oral pour préciser ce qu’il souhaitait dire, tout comme s’il était au tableau. Quand tous les tickets ont été positionnés et regroupés par thème abordé, la rétro peut tout à fait continuer via le support PowerPoint. L’avantage de ce genre de rétrospective est qu’aucun post-it ne tombe de manière insistante et que le compte-rendu final est très propre. Une fois l’habitude prise, l’équipe s’est très bien prêtée au jeu et faire ce genre de réunion ne présentait plus vraiment de contraintes d’organisation.

Voici un exemple de document produit en fin de rétrospective :

La Démo

La démonstration du travail réalisé est, selon moi, une étape essentielle pour la valorisation du travail d’une équipe et influe sur son engagement. Le contexte du projet était très spécifique car une grande réunion était organisée tous les mois pour que les 14 équipes Scrum présentent et partagent leurs réalisations. Les démonstrations se déroulaient à distance car elles s’adressaient principalement aux Américains et aux PO péruviens. Le format WebEx imposé se prêtait plutôt bien à l’exercice et je n’ai jamais vraiment rencontré de difficulté sur ce rituel. Qu’elle soit autour d’une table ou à distance, une démo réussie repose principalement sur un bon support de présentation (Powerpoint sous WebEx), des données crédibles et des scénarios fonctionnels. L’objectif est de se mettre à la place de l’utilisateur final et de montrer comment une évolution lui est bénéfique.
Les démonstrations sont généralement faites par les développeurs eux-mêmes. Dans cette mission et avec le soutien de l’équipe, je me chargeais de présenter les fonctionnalités qu’ils avaient réalisées. J’aimais bien ces réunions car elles me permettaient de promouvoir le travail de l’équipe et d’avoir un rôle bien spécifique que je me suis construit sur mesure petit à petit. Les développeurs étaient bien contents de ne pas avoir à consacrer du temps pour préparer une réunion, de ne pas avoir à parler en anglais devant une grande assemblée et surtout de ne pas avoir à répondre à des questions parfois très fonctionnelles ou en relation avec des fonctionnalités qu’ils pouvaient ne pas connaître. L’environnement des démos n’était pas particulièrement bienveillant et il s’agissait d’un passage obligé imposé par les Américains. L’un des objectifs pour nous était de montrer qu’on était tout à fait capables de livrer des fonctionnalités de qualité et d’être considérés comme une équipe à part entière, sur un pied d’égalité avec les Indiens avec lesquels nous nous sentions en concurrence. Après deux années à se battre, nous avons réussi à nous intégrer à cette organisation complexe et être une équipe reconnue sans distinction avec les équipes historiques.

Conclusion

Pour ceux qui ont eu le courage de lire jusque-là, vous aurez compris que mon rôle de Scrum Master était assez éloigné de la définition du Scrum Guide. Néanmoins, les problématiques rencontrées sont très proches. Le point essentiel pour lequel je me suis particulièrement battu aura été de trouver ma place et de me sentir utile à cette équipe. Je dois dire que mes deux dernières années passées à travailler de chez moi m’ont beaucoup aidé. Tout comme pour un Scrum Master sur place, j’ai cherché à me rendre disponible et à protéger mon équipe. Je gérais les réunions très tôt avec les Indiens ou très tard avec les Américains ou les Péruviens afin de laisser l’équipe se focaliser sur les livrables et l’amélioration de la solution. Bien que le Scrum Guide ne recommande pas que le Scrum Master assure à lui seul la communication, dans notre contexte et au vu de la complexité qu'engendrait cette communication, c'est moi qui m'en chargeais. Pour pouvoir embarquer une fonctionnalité, il fallait obtenir des approbations de personnes différentes pour les spécifications (fonctionnelles et techniques), les plans de test, l’UX… Rebelote pour valider les développements et pousser la fonctionnalité en production. Je n’ai jamais revu une telle exhaustivité sur des Definition of Ready et Definition of Done.

Il y a quelques semaines, j’étais à Sofia en tant que touriste et j’ai beaucoup discuté avec mes anciens collègues. Ils m’ont dit alors qu’ils s’étaient surtout rendu compte de l’importance de mon rôle une fois que j’étais parti car ils avaient récupéré tout un tas de sollicitations externes très chronophages. C’est là le rôle ingrat du Scrum Master. Quand il est là tout le monde se demande à quoi il sert réellement et quand il n’y est plus, tout devient plus compliqué.