Mob programming pour mieux collaborer

REX et boîte à outils

“Mob programming, la véritable approche du développement en équipe” est un retour d’expérience (REX) d’une équipe de Ouest-France, d’ailleurs seule pratiquante de l’entreprise. C’était intéressant de voir ce qu’en tire une équipe déjà très mature quant à ses pratiques : no estimate, pair programming, revue de code, TDD… Forcément, j’étais ravi d’apprendre que le terme mob programming vient du livre “Extreme Programming Perspectives”. Quoi de plus logique finalement que de pousser encore plus loin la pratique du pair programming ?

Pour la présentation “Ensemble Programming Toolbox” par Thomas Carpaye et Hadrien Mens-Pellen, je m’attendais à des tips et tricks et de l’outillage technique. Pourtant, le fils conducteur était ✨ les émotions ✨
Les reconnaître, se demander comment on se sent, et pour chacune, des solutions étaient suggérées. La colère de ne pas pouvoir adopter une pratique librement. La peur, que moi-même je ressens, de se lancer et de se mettre en avant quand on est par exemple au clavier.
Je ne m’attendais donc pas à ça, mais c’était en fait une excellente surprise.
Contrairement à ce que je pensais, pas de Live Share ou de Code Together. Ces outils permettent d’éditer différentes parties du code à plusieurs. Ils sont donc contraires à la règle

“Un pilote et tout le monde participe”.

En effet, si chacun édite sa partie on perd le focus, il n’y a plus de discussion sur un sujet, ni de partage de connaissance.
Finalement, un simple partage d’écran suffit.

Dans les deux conférences, et souvent quand on parle de développement à deux ou en groupe, on évoque le manager “Shérif” qui voit une équipe entière autour d’un seul clavier/écran, façon travaux publics.
Mon opinion personnelle est tout simplement que ça n’est pas son rôle. “Scrum ou le manifeste agile” parlent d’équipe auto-organisée, et la seule métrique qui devrait inquiéter le manager est ce qui est produit et sa qualité. Le choix des pratiques de l’équipe devrait être libre.

Thomas et Hadrien proposent 5 KPI utiles à regarder :

La dernière étant pour moi la principale : est-ce que le client est satisfait ? Est-ce que l’équipe retire de la valeur voire de la joie de cette pratique ?

C’est d’ailleurs satisfaisant de voir les deux conférences se répondre. Par exemple, la première liste comme défaut le fait qu’une équipe qui mobbe est souvent injoignable. La deuxième propose la technique Pomodoro comme solution : pour faire des pauses régulières et rester concentré, on travaille par tranche de 25 minutes. La pause entre deux sessions est alors idéale pour reboucler avec la personne qui voulait joindre l’équipe.

Expérimenter

Finalement, les deux présentations ont peu parlé des outils, ceux-là même qui me paraissaient être un frein. On en revient aux fondamentaux : les individus et leurs interactions plus que les processus et les outils. Tout simplement car le facteur humain est toujours le plus complexe.
Expérimenter réellement, ça n’est pas se contenter de faire une session de mob une après-midi. La dynamique de groupe d’une équipe se met en place sur la durée. C’est aussi échouer pour apprendre, passer du temps à convaincre ses collègues, parfois son management. Essayer une fois, ce n’est pas vraiment essayer.

Vous me croiserez donc sûrement à un meetup de Mob Programming Fr ou bien en train d’animer un coding dojo chez Conserto.
Pour tester.

---

La communauté des Explos est composée d’expertes, d’experts et/ou d’enthousiastes qui aiment développer leurs compétences techniques et partager leur savoir. Conserto leur donne du temps à consacrer aux sujets de leur choix.

Découvrez le replay de ces 2 conférences