Lors de DDD Europe 2020 nous (Anthony et Colin) avons assisté au talk d'Elisabeth (Lisi) Hocke : A Story of Mob Programming, Testing and Everything.  Cette heure nous a permis d'y voir plus clair sur cette pratique formalisée par Woody Zuill et son équipe.

Ce rappel nous a donné envie de revenir sur cette manière de travailler souvent incomprise et sous-estimée !

Mob Programming: Késako ?

Une traduction pourrait être "programmation collective" : l'idée est que toute l'équipe va travailler en même temps à la résolution d'un même problème ! Pour ce faire on utilisera donc l'intelligence collective mais un seul clavier et une seule souris.

On va configurer la salle de cette manière :

Comme en pair-programming le Driver est responsable du clavier : il code dans la direction donnée par le Navigator. Seul le Navigator donne des directions au Driver mais le Mob donne son avis au Navigator qui doit alors les compiler pour en faire des directions claires.

Le Navigator ne doit pas dicter le code qui doit être écrit et le Driver ne doit pas prendre de décision seul, enfin, normalement...

Dans une session de Mob programming tout le monde change de rôle à intervalle régulier (on peut utiliser mobster pour gérer ce changement de manière fluide). Toute personne participant à la session sera donc, à un moment donné, Driver, Navigator et Mob.

En fonction du but de la session : apprentissage ou processus de travail, il faudra faire quelques adaptations à la session (mais ça nous allons le détailler plus tard dans cet article).

Les premières réactions

Quand on présente le Mob Programming pour la première fois la réaction la plus fréquente est certainement : "On n’a pas le temps !". En fait il est commun de penser que cette pratique fait perdre du temps à l'équipe.

C'est vrai, comment, en ayant moins de personnes qui codent, on pourrait faire la même quantité de code ? En fait on ne pourra pas mais, comme le dirait le père de Woody : "I'd rather work slowly on the right thing than quickly on the wrong thing" ("Je préfère travailler doucement sur ce qui doit être fait que rapidement sur des choses inutiles").

C'est bien là le secret de l'efficacité de cette pratique : on codera certainement moins, mais on le fera pour des choses plus utiles. Woody dit : "What do you mean by being productive? Focus on effectiveness instead!" ("Que veut dire être productif ? Concentrez-vous plutôt sur l'efficacité !").

Lors d'échanges avec des collègues pratiquant au quotidien l'un d'eux nous disait "C'est comme si on attaquait tous les problèmes au bazooka ! Quand on rencontre un problème la personne qui a l'information est forcément là donc on a tout de suite la réponse.".

Comme pour toute pratique, il est essentiel de la mettre en place pour se faire réellement un avis ! Les premières sessions peuvent être source de stress, vous aurez donc des premières réactions différentes, mais cette fois ce sera de la part des participants.

Un des rôle les plus impressionnant est sans doute celui du Driver. Faire du Live Coding est tout sauf aisé ! Pour faciliter le démarrage on pourrait être tenté de faire commencer les développeurs les plus expérimentés : c'est surement une erreur ! Les personnes passant après ne seront que plus gênées de "ne pas aller aussi vite" ou de "ne pas connaître aussi bien le langage". Faire commencer les personnes les moins expérimentées peut alors être une bonne idée car elles ressentiront moins le besoin de justifier les inévitables erreurs. De plus, en commençant, leur stress aura moins le temps de se construire pendant le passage des "anciens" de l'équipe.

Le rôle du Navigator peut aussi être source de stress : arriver à prendre en compte les avis de tout le monde tout en étant capable de prendre des décisions pour donner une direction claire au développement n'est pas toujours chose aisée. Pour les premières sessions, il est essentiel que le facilitateur protège le Navigator, par exemple en rappelant que chaque personne doit parler à tour de rôle.

Le rôle de Mob peut aussi être stressant, certaines personnes vont être "complexées" de ne pas être aussi à l'aise que d'autres avec les notions métier ou technique. Certains peuvent aussi se "fabriquer" du stress en comptant le temps restant avant leur passage et en paniquant par anticipation. Dans ce genre de cas, c'est au facilitateur de détecter ces comportements et de  rassurer les personnes (une simple blague du facilitateur expliquant que lui aussi est perdus peut très bien fonctionner). Il est aussi très important que le Mob participe et c'est au facilitateur de s'assurer de cela.

Dans tous les cas il est essentiel de travailler en bonne intelligence. Le but de la session doit clairement être affiché dès le départ et tous les participants doivent travailler à l'atteinte de ce but.

Les sessions ne fonctionnent bien que si tout le monde traite les autres avec considération et respect ! Il est aussi essentiel que chacun reste dans son rôle.

Le Mob Programming comme méthode d'apprentissage

Cette pratique peut être utilisée comme une technique d'enseignement et d'apprentissage. Si c'est le seul but des sessions, on n’utilisera pas de réels problèmes, mais des kata de code qui seront bien plus adaptés et réduiront le stress des participants.

Dans cette optique, il est fréquent que les formateurs ne participent pas au Mob au même titre que les personnes formées, mais qu'ils restent Facilitators.

Il est aussi possible que trop de personnes se présentent à la session, on pourra alors avoir cette configuration :

Dans cette configuration on peut laisser une place de Mob libre en permanence pour permettre aux personnes de l'Audience de rejoindre si elles le souhaitent. Si une personne de l'Audience prend une place de Mob, alors un Mob doit rejoindre l'audience.

Ce format étant particulièrement éprouvant, il est fortement conseillé de faire des sessions relativement courtes (2h). Il faut aussi bien préciser qu'il est tout à fait possible de partir pour mieux revenir si on le souhaite lorsqu'on est Mob ou Audience.

Dans une optique de formation, le formateur a un superpouvoir : il peut demander à être le prochain Navigator et ainsi remettre le groupe dans une direction plus appropriée.

Même si le dispositif semble relativement simple, il est redoutablement efficace en termes d'enseignement ! Il permet à chaque participant :

• D'apprendre des manières de faire des autres ;
• De coder sous contraintes (changement de matériel, live coding, …) ce qui est très formateur ;
• D'apprendre à faire des revues et des retours ;
• D'apprendre les techniques et outils qui sont en cours d'enseignement sous contrôle des formateurs.

Comme à la fin de chaque session de formation, pensez à faire une rapide rétrospective. Cela peut être quelque chose d'aussi simple qu'un Return On Time Invested, mais il est important de prendre les avis (et surtout d'essayer de comprendre les plus mauvais pour faire mieux la prochaine fois).

Le Mob Programming comme processus de travail

Lorsqu'on utilise le Mob Programming comme processus de travail dans une équipe, en plus des avantages que l'on y trouve en l'utilisant comme méthode d'apprentissage, on va :

• S'assurer de travailler sur les tâches réellement importantes ;
• Eliminer les changements de contextes ;
• Limiter le Bus Factor en partageant instantanément les informations ;
• Accueillir simplement de nouvelles personnes ;
• "Attaquer les problèmes au bazooka !".

Enfin, ça, c'est quand tout se passe bien et pour ça, il semblerait que quelques astuces soient nécessaires ! Déjà sur le plan matériel : branchez un clavier "normal" (un AZERTY en France) et une souris pour que les inputs soient classiques.

Assurez vous aussi de trouver un écran permettant vraiment la lecture du code : une télé de 55" coûte moins qu'une journée de prestation, ce serait dommage de s'en priver. D'ailleurs, il est fortement recommandé de faire ces sessions dans le bureau de l'équipe, car il peut être compliqué de réserver des salles de réunions.

Pour commencer, il est préférable que quelqu'un assure la facilitation. Cette personne aura plusieurs rôles :

• Expliquer le fonctionnement du Mob Programming en début de session ;
• S'assurer que chacun respecte son rôle ;
• S'assurer que les échanges se fassent en bonne intelligence ;
• Animer une courte rétrospective finale.

Même s’il est tout à fait possible de travailler tout le temps en Mob, il est sans doute préférable de commencer par des sessions de 2h avec 10 mn d'introduction et 10 mn de rétrospective finale. Pour les premières sessions, il est recommandé de choisir des scopes très légers quitte à avoir de bonnes surprises !

Quand on veut utiliser le Mob Programming comme méthode de travail, il est courant de vouloir avoir toute l'équipe présente. En fait c'est comme ça que doivent se faire les sessions dans l'idéal (avec les développeurs, PO, etc). Malheureusement, il est souvent très compliqué d'avoir tout le monde pendant plusieurs heures !

Il est tout à fait possible d'être moins strict. En laissant les gens rejoindre et quitter la session de Mob comme ils veulent / peuvent, vous allez non seulement faciliter l'organisation, mais aussi rendre le déroulement moins éprouvant !

La dernière chose à laquelle il faut prêter une attention toute particulière est de laisser tout le monde s'exprimer. Au début, il peut être bon de laisser les personnes les plus juniors de l'équipe parler en premier : cela facilitera leurs interventions et permettra à tout le monde d'entendre leurs idées. Il est toujours plus compliqué pour un junior de donner son avis lorsqu'une personne senior vient de donner un avis tout à fait contraire au sien !

Quand ne faut-il pas faire du Mob Programming ?

Il est possible de faire du Mob pour beaucoup de choses (et pas forcément pour du développement). On peut par exemple penser à l'écriture de mails compliqués ou à la rédaction de documentation. Il existe cependant des cas ou le Mob n'est pas recommandé.

Si des tensions existent dans l'équipe, il est fort probable que les sessions de Mob ne fassent que les accentuer. Dans ce genre de cas, il est probablement préférable de régler les tensions avant de se lancer dans une pratique qui peut être stressante.

Faire du Mob peut aussi être une mauvaise idée si trop peu de personnes sont disponibles. Si seulement 2 personnes de l'équipe sont disponibles, c'est du pair-programming.

Il est aussi peu pertinent de faire une session de Mob pour la réalisation de tâches trop simples et maîtrisées par toute l'équipe. Attention cependant : des tâches simples pour certaines personnes peuvent être de vraies découvertes pour d'autres !

Un autre cas qui peut venir à l'esprit : lorsque la fonctionnalité ne doit pas être dévoilée et que seules quelques personnes ont le droit de travailler dessus. Même si ce genre de cas est plutôt rare, il faut penser à les prendre en compte et ne pas afficher la fonctionnalité à des personnes n'ayant pas les autorisations nécessaires.

Quoi qu'il en soit le Mob Programming est adapté dans la majorité des cas, pas d'excuses pour ne pas se lancer donc !

Et personnellement, qu'est-ce qu'on y gagne ?

Aux gains déjà conséquents pour l'équipe s'ajoutent les gains personnels, pour Lisi c'est :

• L'écoute ("Listening"),
• L'Empathie ("Empathy"),
• Aider les autres à grandir ("Helping others grow"),
• L'observation ("Observation"),
• La collaboration synchrone ("Synchronous Collaboration"),
• La communication ("Communication"),
• Laisser de la place ("Making space").

Elle nous a expliqué avoir grandi au travers des sessions de Mob qu'elle a vécues avec son équipe. Avec ce talk inspirant elle nous a donné envie de mettre en place ces sessions de manière plus régulières et, peut être, en sortirons nous, nous aussi, grandis !