Suite de l’article “Témoignage sur le parcours d’ingénieur DevOps/Cloud à Scrum Master “

Dans mon article précédent, je vous ai évoqué mon rôle de Scrum Master que j’occupe depuis le début de cette année chez un client reconnu du secteur des télécommunications. Pour rappel, l’équipe n’avait jamais travaillé avec le framework Scrum. Elle s’est agrandie entretemps, nous sommes passés à cinq « Product Owners » (Ce sont des ingénieurs DevOps avec un profil techlead qui ont une vision globale sur l’infrastructure des applications et qui occupent ce rôle à mi-temps car l’intégration de Product Owners à plein temps n’a pas été jugé nécessaire par le client) et onze ingénieurs DevOps. Nous constituons donc une Scrum Team de dix-sept membres. Par rapport à ce qui est préconisé dans la version 2020 du Scrum Guide : « La Scrum Team doit être suffisamment petite pour rester réactive et assez grande pour accomplir un travail significatif durant le Sprint, habituellement dix personnes au plus », nous dépassons de facto le nombre total de personnes me direz-vous, et bien il a fallu s’adapter aux exigences du client qui souhaite, pour des raisons opérationnelles, conserver ce schéma organisationnel.

Nous avons également une autre contrainte importante : compte tenu de la crise sanitaire actuelle, nous devons travailler à distance, certains membres sont même en full remote du Sud de la France. Par conséquent, nous devons faire en sorte de rester solidaire et d’être le plus efficace possible.

Dans un premier temps, je vais vous présenter comment se déroulent nos évènements agiles avant de basculer sur notre communication au quotidien.

Les évènements Agiles

 

Le daily meeting

Les daily meetings ont lieu le matin deux jours par semaine et ce pour une durée de trente minutes. La fréquence des daily meetings a été déterminée en fonction de l’emploi du temps de l’équipe qui est impactée par différents événements : les daily meetings des multiples trains SAFe, les récurrences (chaque jour, un membre de l’équipe est de récurrence c’est-à-dire que le membre de l’équipe est disponible toute la journée pour aider les interlocuteurs dans le besoin et répondre à leurs questions), les astreintes de nuits, les incidents en production et ainsi de suite. Quant à la durée, elle est définie par rapport au nombre de membres que nous avons dans la Scrum Team : chaque personne doit pouvoir avoir un temps convenable pour s’exprimer. Contrairement à un daily meeting en physique, il faut explicitement citer celui qui va d’abord prendre la parole puis ainsi de suite, je veille à changer l’ordre pour ne pas tomber dans une mauvaise routine. Lors de nos premiers daily meetings, nous avions tendance à focaliser les prises de parole sur les questions habituelles du type :

• Sur quel sujet ai-je travaillé la veille ?
• Sur quel sujet vais-je travailler aujourd’hui ?
• Quels sont les points bloquants que je rencontre ?

Comme nous sommes à distance et en conférence téléphonique (sans webcam), il n’est pas évident de savoir si l’équipe écoute celui qui est en train de parler et donc de susciter l’intérêt et la curiosité sur ses propres sujets. Lors des premières rétrospectives, la Scrum Team a remonté que cette manière d’aborder le daily meeting n’était effectivement pas celle qui procurait le plus d’engouement, il fallait rapidement trouver une meilleure solution pour y remédier. C’est pourquoi nous avons décidé d’opter pour les axes de discussions suivants :

• S’il n’y a pas de sujets particuliers à évoquer, la personne « passe son tour ».
• S’il y a des points bloquants, la personne résume en quelques mots l’obstacle qu’elle rencontre et peut essayer de voir plus en détails avec d’autres personnes de l’équipe après le daily meeting.
• S’il y a un succès à partager, nous n’hésitons pas à féliciter les membres de l’équipe qui y ont participé et ils peuvent, pour ceux qui seraient intéressés, faire une rapide présentation soit après le daily meeting soit en rétrospective.

Depuis ces changements, les daily meetings paraissent plus dynamiques pour la Scrum Team et parfois même, nous arrivons à terminer au bout de quinze minutes au lieu de trente minutes habituellement.

Le backlog refinement/Le sprint planning

 

Dans le Scrum Guide, le backlog refinement et le sprint planning ont lieu séparément. Dans notre cas, pour ne pas multiplier le nombre de réunions, nous avons statué sur l’idée de les réunir sous une seule et même réunion.

Comme de nouveaux sujets peuvent survenir de manière aléatoire et qu’il faudrait les rajouter dans les sprints en cours pour les traiter incessamment sous peu si la priorité est de type « urgente », nous avons par conséquent choisi de fonctionner en « Scrumban ».

Les sprints durant un mois, nous avons en général deux sessions afin d’avoir plus de souplesse et réduire le temps de réunion. Pour le moment, seuls les Product Owners y participent, l’idée est que dès que l’équipe deviendra plus mature au niveau de Scrum, tous les membres pourront y prendre part.

Concernant le chiffrage des User Stories et des Tasks, ce sont au même titre les Product Owners (pour rappel ce sont les ingénieurs DevOps techleads) qui l’effectuent pour toute l’équipe. Contrairement à ce que nous pouvons voir d’habitude où les Story Points sont chiffrées selon le complexe de difficulté avec la séquence de Fibonacci, nous avons opté pour l’estimation en j/h basée sur l’expérience technique pour s’adapter au contexte du client. Il n’y a pas de vote du fait que chaque Product Owner sait comment estimer les sujets sur son propre périmètre et que les autres Product Owners n’ont pas forcément eu l’occasion de travailler sur les périmètres autres que les leurs.

Ce qui m’a préoccupé pour aider les Product Owners notamment lorsque nous sommes à distance est de mieux se faire comprendre sur la manière de découper les User Stories/Tâches ainsi que de déterminer les story points en question.

Mais, plus récemment, nous avons pu retourner travailler sur site à raison de quelques jours par semaine et cela m’a permis de rencontrer les Product Owners en physique. Cette rencontre a été le moment de discuter des points d’amélioration que nous avons pu mettre en place plus facilement qu’en distanciel. Nous sommes avant tout des êtres humains et nous avons besoin de nous voir en face à face pour construire une relation d’aisance et créer un véritable esprit d’équipe pour progresser ensemble.

La sprint review/La sprint rétrospective

 

Comme pour le backlog refinement et le sprint planning, la sprint review et la sprint rétrospective ont lieu sur le même créneau.

Lors de la sprint review, à défaut de montrer des interfaces web comme ce que font, en général, les Scrum Teams de développeurs, nous avons des démonstrations qui peuvent porter entre autres sur des dashboards Grafana ou des pipelines Gitlab. Concernant cet évènement agile, nous n’avons pas constaté de difficultés lorsqu’il est effectué à distance ce qui est un point positif.

Lors de la sprint rétrospective, nous avions commencé par utiliser l’outil Klaxoon en nous basant sur le template du « Starfish retrospective » comprenant cinq zones à remplir :

• Keep doing
• Less of
• More of
• Stop doing
• Start doing

Chacun a la possibilité d’y ajouter un ou plusieurs post-it dans les zones où il souhaite s’exprimer. Cependant, au fil des rétrospectives, j’ai remarqué que certains membres de l’équipe ne s’exprimaient jamais que ce soit en termes de prise de parole ou d’ajout de post-it. Je me demandais si cela était dû au fait que d’écrire sur des post-it ne leur convenait pas ou qu’ils n’osaient pas se manifester sur ce qu’ils ont pu ressentir au cours des sprints. Après avoir échangé avec eux, il s’avère qu’ils avaient besoin de revoir ce que certains avaient émis comme idées lors des rétrospectives précédentes pour s’en inspirer et développer leurs ressentis. De ce fait, j’ai créé deux colonnes dans les zones en mettant dans l’une, les post-it de la rétrospective précédente et dans l’autre, chaque personne peut y ajouter son post-it. Cette modification a plutôt bien fonctionné, et cela s’est ressenti notamment lors du vote du R.O.T.I. Récemment, nous avons essayé un nouvel outil qui est EasyRétro, dans le but de donner un nouvel élan pour les rétrospectives à distance. Le template que j’ai utilisé est celui du What Went Well qui comporte trois colonnes :

• Went Well
• To Improve
• Action Items

Le procédé est le même à savoir d’ajouter des post-it sous les colonnes correspondantes toutefois comparé à Klaxoon, l’équipe semble être plus motivé, cela est sans doute dû au format plus structuré et moins en mode Brainstorming.

La communication à distance avec l’équipe

 

Pour communiquer avec l’équipe, nous avons différents outils à disposition :

• Skype
• Mattermost (Le « Slack » de Gitlab)
• Un outil interne de conférence téléphonique
• Mail

En tant que Scrum Master, il est primordial de bien communiquer avec chacun sachant que ce n’est pas une chose évidente surtout lorsqu’on n’a jamais rencontré son interlocuteur en face à face. Parmi les outils que je préfère utiliser, ce sont les trois premiers cités ci-dessus, le mail peut être une bonne option mais il ne permet pas de rapprocher les personnes et peut paraître un peu plus formel. Jira est également l’outil que nous utilisons chaque jour mais qui a plus une connotation tacite, il permet à chacun d’apercevoir comment les sujets progressent sans avoir nécessairement besoin de s’adresser à la personne.

La communication orale est beaucoup plus fluide pour la compréhension que la communication écrite, il n’y a pas de temps d’attente et elle permet d’avoir les informations en temps réel, bien entendu, elle permet également de deviner l’humeur de l’interlocuteur et d’adapter son discours en fonction du contexte.

Conclusion

 

La crise sanitaire a contraint les Scrum Masters à revoir leurs habitudes de travail avec leurs équipes tout en essayant de maintenir une dynamique et en conservant une frontière entre vie professionnelle et vie personnelle. Le rôle de Scrum Master est un rôle qui nécessite de nombreux soft skills comme par exemple savoir rassembler, apaiser les tensions ou impulser de la motivation au sein de l’équipe. Le fait d’être en télétravail donne la possibilité d’apprendre à les utiliser d’une autre manière ce qui constitue une expérience plutôt enrichissante et pleine de rebondissements. Par ailleurs, le télétravail qui s’est amplifié, va accentuer l’utilisation des outils numériques qui ne cessent de se développer de jour en jour. Malgré tout, les relations sociales restent très importantes et se ressentent avec les retours sur site, les pauses café et les déjeuners d’équipes. Revenir une partie en présentiel donne la possibilité de se retrouver et de souffler par rapport au quotidien virtuel qui ne pourra pas remplacer la proximité visuelle que nous pouvons avoir avec chacun.