Le contexte

Pour commencer, un peu de contexte… J’interviens actuellement en mission dans un grand groupe en tant que Scrum Master, dans un contexte SAFe. Nous arrivons à la fin de notre Program Increment (PI). Et comme à la fin de chaque PI, dans ce contexte client, chaque équipe dispose de 2 jours d’expérimentation pour tester des pratiques, des nouvelles solutions techniques, ou autre. Le but étant de prendre un moment pour innover ou pour s’améliorer en allant plus loin que ce que nous avons le temps de faire en général sur les sprints.

L’équipe que j’accompagne a récemment subi des changements, avec 2 départs et 3 nouvelles arrivées, dont moi-même, depuis le début d’année. Il est probable qu’elle continuera d’évoluer à l’avenir. De plus, nous sommes répartis sur plusieurs sites entre France et au Portugal. Depuis les 2 dernières arrivées, qui ne parlent pas français, nous avons commencé à travailler en anglais. Ce changement complique parfois les échanges et donc notre capacité à collaborer efficacement.

Mon intention

Dans ce contexte, j’ai proposé d’essayer du Mob Programming, bien que l’équipe collabore efficacement et aie notamment l’habitude de fonctionner en Pair Programming, quand elle en ressent le besoin. Nous pourrions penser que ce type d’expérimentation n’est pas adaptée dans ce contexte d’équipe déjà efficace. Mais je suis convaincu que ce moment sera bénéfique pour l’équipe, notamment en termes de collaboration, de partage de connaissances et de bonnes pratiques. D’autant plus, que j‘en ai profité pour alimenter ces sessions de Mob Programming avec d’autres pratiques.

La première demi-journée ayant été occupée avec une réflexion autour de nos processus de livraison et de notre workflow git, nous avons lancé la démarche l’après-midi.

Mob Programming : la démarche

Dans cette section, nous allons décrire la démarche de Mob Programming que nous avons expérimentée. Nous allons expliquer les rôles et l’importance de la rotation. 

Nous avons commencé par une explication des rôles du Mob Programming : 

  • Driver : responsable de l’écriture du code, de suivre les instructions du Navigator, et ne doit pas prendre de décision par lui-même.
  • Navigator : responsable de guider le Driver et de conduire les échanges avec l’aide du groupe.
  • Mob (le reste du groupe) : aide le Navigator en répondant à ces questions et en partageant des infos supplémentaires. Tout le monde s’assure que la parole de tous et toutes est écoutée et que les discussions sont positives.

La rotation des rôles est cruciale dans le Mob Programming. Elle permet de ne pas décrocher par ennui, d’avoir une compréhension globale du projet, et de mieux intégrer les nouvelles compétences expérimentées. Etant à distance, ce qui est une contrainte dans ce type d’exercice, j’ai proposé des rotations de 10 minutes afin que la rotation soit régulière tout en laissant suffisamment de temps pour avancer pendant une rotation.

La technique Pomodoro

Afin de rythmer le temps au mieux et de respecter les besoins de pause de chaque membre de l’équipe, j’ai présenté la technique Pomodoro. Le principe est de couper chaque session de travail de 25 minutes, par une pause de 5 minutes pour souffler. Au bout de trois sessions de 25 minutes, une pause plus importante de 15/20 minutes est prise.

Cette technique permet de favoriser l’agilité intellectuelle, que nous pourrions résumer par la capacité à réagir et à s’adapter aux événements, ainsi que la capacité à passer d’une idée à l’autre de façon fluide.

Cycle Mob + Pomodoro 

Pour résumer ces 2 premières parties, voici le cycle comprenant les rotations liées au Mob Programming incluses dans la technique Pomodoro :  

Pour gérer ce cycle, nous avons utilisé un outil intitulé “Mob Time”, développé par Hadrien Mens-Pellen. Il permet de configurer la durée de chaque rotation et de chaque cycle Pomodoro. De plus l’outil, gère lui-même les rotations de rôle et est vraiment très simple d’utilisation.  

Première expérimentation 

L’équipe étant assez conséquente et ayant 2 sujets fonctionnels à aborder nous avons décidé de scinder l’équipe en 2 groupes de 4. Le premier sujet était une correction à la suite de tests effectués en recette, tandis que le second était un nouveau besoin. Ces 2 sujets étaient l’occasion de tester notre nouveau workflow Git, que nous venions de faire évoluer le matin même, à la fois sur la gestion des “features” ou sur celle des “bugfix”. 

De mon côté, j’ai pris un rôle de facilitateur, en naviguant entre les 2 groupes pour répondre aux éventuelles interrogations et pour observer le déroulement de l’expérimentation. 

Chaque groupe a pu travailler, sur le sujet qui lui a été attribué, pendant environ 2 heures avant que nous nous réunissions pour tirer des conclusions de cette première tentative. 

Les premiers retours 

Durant cette phase de débriefing, j’ai orienté autour de 3 questions : 

  • Comment vous sentez-vous après cette session ? 
  • Qu’avez-vous découvert ? 
  • Sachant que nous allons refaire une session le lendemain, comment voulez-vous faire évoluer cette pratique ? 

Les 2 groupes ont passé un bon moment bien que certains ont dû s’absenter pour participer à des réunions. Je note qu’il est compliqué de bloquer toute l’équipe pendant 2 jours la semaine précédant le prochain PI Planning.  

Un conseil serait peut-être de prévoir ce type d’expérimentation sur des moments un peu plus calmes.

La démarche a été particulièrement appréciée par les personnes récemment arrivées car elle a permis de découvrir et de partager la façon de travailler de chacun. 

Concernant le rythme, les retours sont assez unanimes sur le fait que le temps entre 2 rotations était trop court. Même s’il a été noté que les rotations fréquentes permettent à tout le monde de rester concentré durant tout la durée de l’expérience. De mon point de vue, notre contexte joue beaucoup. Sachant que nous étions tous à distance les uns des autres, qu’il n’y a pas de norme en terme de choix ou de version d’IDE dans l’équipe, et que les règles de sécurité de l’entreprise ne nous ont pas permis d’installer la librairie mob.sh. De ce fait, chaque rotation nécessitait un commit sur Git et une prise de contrôle du partage d’écran. Nous repartons avec l’idée d’essayer un rythme différent, et à définir, le lendemain.

Seconde expérimentation avec TDD 

Le lendemain matin, nous nous sommes retrouvés pour une seconde expérimentation. Suite aux retours de la veille, il a été décidé de changer le temps entre 2 rotations de rôles. Nous avons décidé de ne plus faire qu’une seule rotation par cycle Pomodoro. 

Ayant du temps devant nous, et pour sortir des sujets fonctionnels classiques, nous sommes partis sur le kata Mars Rover.  

Une règle sur ce kata est d’utiliser la stratégie Test Driven Development (TDD). L’utilisation du TDD étant une aide pour mener à bien la réalisation de cet exercice. 

L’équipe a décidé de repartir sur les mêmes groupes que la veille. J’ai donc repris mon rôle de facilitateur/observateur. 

Quelles différences avec la première session ?

Le nouveau rythme semble avoir été plus apprécié. Et j’observe que les groupes ont pris plus de liberté avec les timings. J’avoue m’être dit que c’était ok pour moi, en espérant que cela rende l’expérience plus agréable.

Une seconde différence, et non des moindres, c’est le fait d’être parti sur un kata. Cette décision a permis que tout le monde parte du même pied d’égalité et de mieux répartir la parole. Autrement, le risque, observé la veille, est qu’un expert prenne le lead lors de la réalisation d’un ticket. 

Bilan final 

Le bilan est extrêmement positif et encourageant. Le fait de prendre le temps de se poser en équipe et de tester le Mob Programming a plu. Il semble que chacun ait apprécié ces moments de travail en groupe. 

Certains ont découvert le TDD, et à première vue, cette pratique devrait être ré-utilisée à l’avenir. De mon côté, n’étant pas un expert en TDD, j’ai plutôt encouragé à suivre les étapes décrites dans le kata, pour éviter de partir dans une mauvaise direction. J’ai conscience que le TDD est un sujet qui mériterait d’être creusé dans l’équipe afin d’avoir une vision plus précise de celui-ci. 

Le fait de devoir s’exprimer en anglais a été un frein pour le kata Mars Rover. Ce kata nécessitant de bien se comprendre pour creuser la partie modélisation. Malgré les 4 heures passées sur ce kata, aucun des 2 groupes n’est arrivé au bout, bien que ce n’était pas forcément un objectif.

De mon côté, j’observe que les interactions s’améliorent avec ce genre de pratiques. Chaque membre prend conscience de l’importance de ne pas prendre le lead, de ne pas rester ancré sur ces idées, et d’être dans une posture d’écoute. 

Pour finir, nous nous réunissons tous pour le PI Planning la semaine suivant, certains pour la première fois. J’ai la sensation, et peut-être l’espoir, que d’avoir pris ce temps va permettre de rendre les échanges à venir encore plus fluides.

Pourquoi cet article ? 

J’ai écrit cet article car je trouvais intéressant de partager les bienfaits du Mob Programming pour s’améliorer en tant qu’équipe. 

De mon côté, je ne suis pas du tout un expert des pratiques mises en avant, bien que je les connaisse et sois convaincu de leur utilité. Cependant, cela ne m’a pas empêché de les proposer, de les expliquer, et de lancer ces expérimentations.  

Du coup, si vous lisez ces lignes, n’hésitez pas à mettre en avant ces pratiques (Mob Programming, Pomodoro, TDD), ni à les tester en équipe. Vous ne risquez pas grand-chose, à part de permettre à vos équipes de mieux collaborer ! 

Quelques ressources

Pour aller plus loin

Liens utiles

Image