Pour poser un peu de contexte, nous sommes une vingtaine dans l’équipe, composés de multiples profils (tech, produit, terrain, design, …). La plupart sont situés en Île-de-France et les autres répartis dans différentes régions du pays. Il y a une seule règle autour du télétravail : on veut se retrouver tous ensemble physiquement les derniers jeudis du mois. Le reste du temps, chacun est libre de s’organiser comme bon lui semble - et c’est majoritairement à distance.

Ce qui m’a valu des questions de la famille, d’amis, d’autres collègues. « Pas trop dur d’être souvent en télétravail ? Tu te sens comment ? » Et même des affirmations « ah moi je pourrais pas ». Alors j’explique certains aspects que j’aime bien - flexibilité, auto-orga, temps libéré, etc. Des choses qu’on entend déjà bien assez avec les fervents défenseurs du télétravail sur LinkedIn.

J’explique qu’aussi, je me sens bien avec le télétravail dans cette équipe (j’insiste sur ce point) parce que j’ai l’impression d’avoir mes collègues à côté de moi. Tout le long de la journée, j’ai beaucoup d’échanges, du spontané, de l’informel, du lien. Du sérieux et des conneries. Je ne suis pas seul au final. Et là, je vois que je mets le doigt sur quelque chose. « Ah ouais, c’est pas mal », « Faut qu’on essaie ça chez nous ».

Je pense qu’un des ingrédients principal de notre télé-mayonnaise est notre utilisation de Discord.

Rester connecté vocalement

Je vulgarise pour ceux qui ne connaissent pas. Discord est une application qui permet à plusieurs personnes de discuter avec du texte et avec de l’audio/vidéo grâce à un système de canaux. Ce qui est particulièrement intéressant ici, ce sont les canaux vocaux.

Un canal vocal est toujours ouvert. On voit les personnes qui y sont connectées actuellement, et on peut les rejoindre (et partir) à tout moment. Par exemple, je vois que Alice et Bob sont sur le canal Kaamelott. Ça tombe bien, j’ai besoin de leurs avis. Je vais m’y connecter brièvement pour échanger avec eux sur ma problématique.

C’est différent des outils classiques comme Google Meet, Microsoft Teams ou Slack. Je n’ai pas besoin d’appeler une personne, ni de planifier une réunion sur un calendrier, ni de demander la disponibilité de quelqu’un. Je rejoins un espace de discussion et hop, je suis avec ces personnes. Je peux immédiatement parler et ils m’entendent. Ou l’inverse. J’étais seul et hop, quelqu’un me rejoint.

C’est très pratique. Et c’est devenu très puissant quand on a commencé à l’utiliser pleinement. Je m’explique. Au début, on l’utilisait pour quelques rituels et on s’envoyait des messages pour se dire « hey tu viens sur Discord 5 min stp ? ». Puis un jour, on a glissé sur un autre mode de fonctionnement.

Avec mes deux collègues devs mobile par exemple, on s’est mis à se connecter sur notre canal vocal « ici c’est le mobile » les matins et on y restait toute la journée*. Même lorsque l’on n’avait pas besoin de se parler ou de travailler ensemble.

Pourquoi ? Pour la spontanéité. À tout moment, je peux activer mon micro et parler avec mes collègues - ils sont déjà là, ils m’entendent et peuvent répondre.

C’est génial pour collaborer. On peut s’entraider, poser une question, réfléchir à voix haute et avoir d’autres avis, déclencher un pair programming à la volée. Ça laisse également plus de place pour de l’informel. On peut dériver d’un sujet, raconter soudainement une anecdote ou le film vu la veille.

Il n’y a pas de friction. On parle, tout simplement. C’est con mais terriblement efficace.

*Connecté toute la journée : bien entendu, on se déconnecte d’un canal si on a autre chose à faire, besoin de focus, ou tout simplement si on a envie de couper. Aucune obligation.

Encore plus accueillant

La semaine dernière, j’ai fais une expérimentation pour aller un cran plus loin. On était content avec ce système dans l’équipe, mais il y avait majoritairement des développeurs connectés sur les canaux. On avait également trop de canaux (20 !) et plutôt silotés - « devs back 1 », « devs back 2 », « mobile », « recette », etc. En discutant avec d’autres profils dans l’équipe, je sentais qu’il y avait un intérêt et qu’on pouvait les embarquer.

Jeudi matin, j’ai tout supprimé puis j’ai créé une poignée de canaux. Différemment.

• Un groupe « Ouvert » avec 5 canaux. N’importe qui peut rejoindre n’importe quand. C’est ouvert. J’y vais pour travailler avec les personnes présentes, pour discuter, juste écouter en fond. Ou j’y vais seul pour que d’autres me rejoignent s’ils en ont envie à un moment.
• Un groupe « Privé » avec 2 canaux. Ici, je suis plutôt focus, je préfère ne pas être dérangé, sauf sujet important.
• Des univers et des lieux comme nom de canal. Quelque chose de générique pour ne pas se fermer sur un métier ou une action. « Kaamelott », « Pixar », « Montagne ».

L’idée que j’avais derrière la tête ce matin-là, qui me guidait, c’était de créer un environnement permettentant aux gens de se croiser plus naturellement. En se groupant, et en se mélangeant. De manière prévue, et imprévue.

J’avais envie qu’une personne soit davantage tentée de rejoindre un canal avec d’autres personnes. Le groupe ouvert va dans ce sens, et les noms des canaux ne sont pas excluants. La réduction du nombre de canaux aide aussi, c’est une contrainte dans le système pour faire croiser les gens. Si on loue un château avec 200 chambres, on se verra trop rarement voire jamais.

En une semaine, il s’est déjà passé des choses très intéressantes.

• De nouvelles personnes de différents profils qui passent régulièrement sur les canaux.
• On s’est retrouvé à plusieurs pour prendre le café un matin avant le daily, discuter un peu du projet et de sujets divers, puis on a eu notre moment improbable quand une personne nous a joué du piano.
• Un verbatim : « Je pensais qu’il manquait un canal privé. Hier soir les deux étaient pris, une personne m’a rejoint car elle en voulait un aussi. C’était bien, on était chacun focus puis on a pu discuter. Ça ne serait pas arrivé, finalement peut-être qu’il n’en manque pas ».
• Et un autre : « Bon, je viens de me relancer dans le visionnage de Kaamelott, je t’en tiens pour responsable ^^ ».

Être à côté… de la plaque

J’avais envie de raconter cette histoire parce qu’on peut facilement se planter sur la façon de travailler à distance et créer des douleurs. En ne changeant rien alors que le contexte, lui, a changé. En saturant les journées de réunions. En restant toujours seul et en ne croisant d’autres collègues qu’à travers des réunions avec d’ailleurs bien trop de monde. En voulant tout contrôler. Etc.

Le télétravail est encore assez jeune pour beaucoup d’entreprises et de personnes - c’était bien moins présent avant le covid. Je trouve intéressant de partager des expériences qui peuvent inspirer et aider d’autres équipes qui se cherchent encore dans leurs relations avec le télétravail. On n’est pas obligé d’en faire, et on n’est pas obligé de le subir non plus. On peut se l’approprier - le problème n’est parfois pas dû au fait de télétravailler mais au comment on en fait.

Chaque équipe et chaque personne a des besoins différents, il faut les prendre en compte et essayer des choses. Tentez et faites différemment, c’est l’opportunité de grandement améliorer le quotidien.

C’était lors d’un beCom début octobre - un événement à benext qui regroupe toute une communauté sur l’après-midi. Les participants étaient demandeur d’approfondir un sujet, notamment avec de la pratique. On a proposé avec Cédric d’animer un Mob-Programming.

J’aime beaucoup faire du Mob-Programming. C’est un excellent moment pour partager, apprendre, et explorer avec plusieurs personnes. On s’est dit que ce serait un très bon moyen pour que le groupe puisse apprendre activement. Que les plus sachant transmettent. Que les plus néophytes découvrent et essayent. Que tout le monde se challenge à son niveau.

Cédric restait au clavier (covid oblige) pour retranscrire toutes les volontés du groupe. De mon côté, je facilitais. Nous étions aussi là en conseil pour accompagner le groupe lorsqu’il y avait besoin.

Trop de libertés, peu d’initiatives

On a démarré avec un format très libre. Tout le monde pouvait participer, proposer et faire avancer à tout instant. Résultat, de nombreux silences et non un brouhaha. Une seule personne participait activement et deux autres de manière sporadique (oui, je suis en manque de Kaamelott). Le reste du groupe était totalement passif.

Un début pas très dynamique, probablement ennuyant pour certains participants. Un début qui me demandait également beaucoup d’énergie pour la facilitation, pour insuffler de la vie, faire participer, faire questionner, etc.

Avec le recul, je me dis que l’on n’a pas assez pensé au public ciblé en amont. Un public composé majoritairement de jeunes développeurs et non habitué à des pratiques tel que le Mob-Programming. Avoir trop de liberté était contre-productif, cela freinait les participants. Et avec 10 personnes, c’était un grand groupe. Il fallait un cadre plus fort.

Des binômes et de l’action

Au bout d’une heure, j’ai proposé de faire un break pour s’aérer l’esprit. On a échangé brièvement avec Cédric et on était du même avis, c’était difficile. On a repris avec une nouvelle formule.

On a désigné deux personnes au hasard. Celles-ci héritèrent du rôle de leader : elles devaient faire des choix, réfléchir à voix haute et indiquer comment avancer à Cédric (au clavier). Toutes les dix minutes, on tournait avec les deux personnes à côté. Et ainsi de suite. Le reste du groupe pouvait bien entendu participer en même temps, mais c’est le binôme qui était responsable de faire avancer.

Rapidement, le Mob-Programming est devenu vivant. Les échanges au sein du binôme étaient intéressants, il y a avait de l’interaction entre les personnes, et le groupe avançait bien. L’ensemble du groupe s’est mis à participer. Les personnes étaient avec nous. Lors du debrief de fin de journée, les retours étaient très positif sur le passage en binômes.

J’avais également moins d’effort à fournir sur la facilitation. Inconsciemment, j’essayais de combler cette absence de cadre en première partie. Le groupe gagnait en autonomie et je pouvais me concentrer sur d’autres choses.

Assigner des rôles et les faire tourner

En assignant des rôles, on a proposé un cadre dans lequel les participants évoluaient. Ce rôle les responsabilisait. Le rôle les poussait à l’action et à la réflexion. Au sein d’un grand groupe, cela évite l’effet “quelqu’un le fera à ma place”.

Faire tourner ces rôles permet de rendre tout le monde actif à un moment. Les participants étaient davantage présents, et le fait de minuter donnait un rythme. Le groupe arrête de se reposer sur une seule personne très active, et celle-ci laisse la main.

Je repense aux sessions de Mob-Prgramming que je fais avec des personnes plus chevronés, en format assez libre : il y a aussi des moments où l’on désigne une personne qui prend le lead. Et des moments où l’on change. Ca fonctionne bien.

Tout ceci me fait dire qu’avoir des rôles tournant, ou au moins un lead tournant au sein du groupe est une composante importante du Mob-Programming. La méthode du Driver & Navigator va d’ailleurs dans ce sens.

C’est quelque chose que j’utilise régulièrement avec mon binôme. Sur la demande de l’un ou de l’autre. Je m’en sers beaucoup pour accompagner, partager mes connaissances, donner du feedback. On a des cas concrets pour échanger, confronter des idées et résoudre des problèmes.

Et puis un jour je me suis dit, tiens, et si on se fixait un moment dédié et régulier pour faire du pair programming ? En conservant toujours la possibilité de le faire spontanément si besoin. L’un n’empêche pas l’autre. Je l’ai proposé à mon collègue et on s’est lancé. On a essayé une fois par semaine, un créneau récurrent inscrit dans l’agenda. On a tenu chaque séance depuis le début. Aujourd’hui, j’ai eu envie de revenir sur cette expérimentation et sur ce que ça nous a apporté.

Pourquoi cette envie de ritualiser ?

Printemps 2020 rime, malheureusement, avec la pandémie de Covid-19. Lorsque l’on a été confiné, mon équipe est passée de quelques rares jours de télétravail par mois à du full remote. Je voulais garder un lien fort de partage avec mon binôme. Sur notre lieu de travail, nous étions côte à côte. Il était aisé de tourner l’écran de manière spontanée et de dire « Hey, qu’est-ce que tu en penses ? » ou « Je suis bloqué ici, tu peux regarder avec moi ? ».

À distance, j’avais peur que l’on perde ça. On ose peut-être moins. Ça demande plus d’effort. Plus de synchro. Il faut demander et appeler. Je pense qu’il peut y avoir une peur de déranger, on ne sait pas ce que l’autre fait à ce moment, on ne le voit pas. La raison première était donc de garder un lien. En ritualisant, je savais que l’on avait un créneau réservé sur nos agendas pour le faire.

Ce que j’en attendais également, c’était de partager encore plus. En faisant régulièrement du pair programming, au moins une fois dans la semaine, je voulais accentuer mon accompagnement. Avoir plus de moments où je pouvais transmettre et échanger.

Qu’est-ce que j’ai observé ?

Beaucoup de bonnes choses. J’ai même envie de dire que des bonnes choses. J’ai été agréablement surpris par chacune de nos séances. On a, à plusieurs reprises, dépassé notre créneau et continué naturellement, parce que c’était utile, parce que ça apportait de la valeur. On s’est beaucoup entraidé avec nos différentes connaissances du métier et du code. La confrontation régulière des idées a permis d’avancer plus vite sur des sujets parfois complexes.

J’ai remarqué un effet canard en plastique. Expliquer son problème à quelqu’un d’autres aide à mieux le comprendre et à trouver une solution. Donc le faire régulièrement (avec plus de pair programming) aide à trouver plus souvent et plus rapidement des solutions. C’est très bénéfique.

Une de mes craintes au départ était « est-ce qu’on aura à chaque fois des sujets adapté au pair programming ? ». En fait, oui. Ce n’est pas du tout un problème. Un jour, j’étais sur une correction de bug assez mystique. Je n’étais pas très avancé dessus et je n’avais pas de pistes intéressantes. Je pensais que ce ne serait pas très intéressant pour le créneau de pair programming qui allait démarrer.

Mais je me trompais. Ce fut l’une des sessions les plus utiles. Avec nos deux cerveaux et nos échanges, on a avancé extrêmement vite sur ce sujet. On a fait du pair programming l’après-midi entière et on a pu corriger ce bug. On a été très productif. Beaucoup plus que si j’étais resté seul.

En plus du gain de productivité et de la résolution de problèmes, j’ai pu beaucoup plus transmettre et accompagner mon binôme avec ces séances de pair programming régulières. Je trouve que c’est un excellent moyen d’apprendre les uns des autres, de guider, d’expliquer, d’essayer. On fait des choses concrètes, ensemble. On code et on échange en direct.

Enfin, une autre conséquence que j’ai observée avec l’augmentation de pair programming est la réduction du temps passé à faire du code review. Elles sont moins nombreuses et plus rapides. Plus on écrit du code ensemble, moins il y a besoin d’un processus où on le relit. Et c’est une bonne chose je trouve. Je préfère faire davantage de pair programming que de code review. Et si on arrêtait les revues de code ?

Le pair programming nous fait collaborer. On partage la propriété du code (collective code ownership), on est capable de comprendre chaque partie. C’est interactif. C’est en direct. Les code reviews sont asynchrones. On échange à l’écrit. On donne du feedback bien après l’écriture du code.

Et maintenant ?

Je compte bien conserver ce rituel et continuer à avoir un créneau dédié au pair programming. Même si le confinement est terminé et que l’on retourne partiellement au bureau, j’aime beaucoup tout ce que le pair programming nous apporte. Le fait de le ritualiser permet d’en faire plus régulièrement. Ca nous apporte un cadre.

Je songe à augmenter notre « temps minimum » de pair programming par semaine. Soit en augmentant la durée du créneau, soit en ayant deux créneaux dans la semaine. Je réfléchis aussi à une variante. Au début d’un sprint, choisir une story et décider de la faire entièrement en pair programming. Du début à la fin.

Une autre idée qui me semble intéressante serait de faire du pair programming avec une autre spécialité de temps en temps (on est organisé en feature team, il y a des développeurs Android, iOS et backend dans l’équipe). De cette manière, on obtiendrait plus de compréhension sur les autres plateformes. On irait également plus loin dans la pluridisciplinarité. J’ai pu le faire à deux reprises au début de l’année avec un développeur Android pour comprendre un problème commun, ce fut très utile.

Bref

L’expérimentation de ritualiser le pair programming s’est révélée très positive. Nous en avons tiré beaucoup de bonnes choses. Du partage, de l’accompagnement, de la collaboration, collective code ownership, etc. Tout ça régulièrement. Nous étions très productifs dans ces moments-là. Les discussions autour de l’écriture du code ont apporté des idées, des résolutions de problèmes, de l’apprentissage.

Je recommande vivement de faire davantage de pair programming. Avoir un créneau dédié peut être un moyen d’y parvenir. Essayez. C’est simple à mettre en place et très efficace. Si vous n’en faites pas du tout, lancez-vous. Si vous en fait de temps en temps, tentez de fixer un créneau. Vous pouvez commencer petit, avec une heure par semaine par exemple. Décidez d’un moment, officialisez-le dans l’agenda, et tenez le.

Et vous, à quel point faites-vous du Pair Programming ? Et comment ?