Dans l'histoire des idées folles, XP - avec à la fois le pair programming et le Test Driven Development - tenait le haut du panier du secteur informatique au moment de son apparition. Le Mob Programming paraît aller encore plus loin : c'est une manière de développer des logiciels où toute l'équipe travaille dans un même endroit, au même moment et sur le même ordinateur.
Woody Zuill s'est exprimé sur le Mob Programming durant la première Mob Programming Conference, où il a déroulé une sorte de FAQ autour du sujet depuis les quatre ans qu'il mobbe.
Ce papier se compose de deux parties, la première reprenant les idées clé de la présentation, puis une seconde avec un entretien avec Woody Zuill sur les différentes manières d'introduire le Mob Programming, les principales difficultés du secteur de l'IT, les autres activités éligibles au mob, et les enjeux du mob.
Présentation : What is Mob Programming about?
En mettant en perspective l'histoire d'XP et les difficultés à expliquer les pratiques techniques à un niveau de direction (non-IT), la question sans cesse posée reste : "comment une équipe de cinq personnes peut-elle être plus productive ?". Woody donne deux réponses :
- Quelle preuve permet de poser que diviser le travail entre plusieurs personnes est plus efficace ? Ce point est assez proche de celui proposé par Robert C. Martin dans sa présentation sur le dernier langage de programmation (EN) et du travail de Peter Drucker sur les "travailleurs du savoir" : l'utilisation de métriques industrielles pour évaluer le travail du savoir est explicable mais n'est pas une preuve étayée (en tout cas pas à ma connaissance).
- L'objectif du mob n'est pas d'être productif mais efficient. Le parallèle se fait avec les pratiques Lean, être productif et non efficient est une bonne manière de produire plus vite des déchets.
Les principales difficultés rencontrées par une équipe développant du logiciel disparaissent avec le Mob Programming. Par exemple :
- Il n'y a plus de problèmes de communication. Toute l'équipe est là, ensemble, avec le même niveau d'information.
- Le Temps d'attente (Queue Time, NdT) pour obtenir des réponses aux questions. Le problème n'est pas la productivité mais l'obtention de réponses. Dans le contexte, introduire de nouveaux stocks dans le backlog est juste un nouveau gaspillage. Travailler ensemble toute la journée évapore le problème.
- La Dette Technique. C'est probablement l'aspect le plus intangible du développement logiciel : en informatique, quand une équipe introduit des déchets dans le produit, ils y restent. La pratique du Mob Programming permet de garantir un haut niveau de qualité.
En 2012, Woody Zuill essayait quelques nouvelles pratiques avec ses équipes chez Hunter. Après quelques discussions sur twitter, il commença à expliquer ce qu'il faisait dans des conférences. Après plusieurs présentations, les mêmes questions revenaient, donc il se décida à écrire quelques slides pour y répondre, en gardant à l'esprit cette citation de Peter Block :
La valeur de l'expérience d'un autre est de donner l'espoir, non de vous dire comment ou s'il faut faire.
Woody posa une question piège : "Pourquoi l'équipe travaille de cette manière". L'assistance fournit littéralement une multitude de réponses, mais la sienne était différente : la seule raison pour une équipe de travailer en mob est parce qu'elle a décidé de le faire.
C'est certainement avec ce point que le Mob Programming colle le plus à l'état d'esprit Agile, et qui est peut être même plus Agile que le Manifeste, un peu comme le posait Alex Krivitsky en 2011 : l'Agile, c'est surtout "les individus et les interactions". Pour le formaliser, le "manifeste du mob" (même si je ne suis pas sûr que quelqu'un l'appelle comme ça) irait ainsi :
Tous les brillants esprits
Travaillant ensemble
Sur la même chose
Au même moment
Dans un même endroit
Sur le même ordinateur
Je vois deux différences principales avec le premier manifeste :
- D'abord, le Mob se concentre sur l'unité d'action. Toute l'équipe (la mob) s'engage à travailler ensemble sur une chose à la fois, et non à diviser le travail entre les individus. C'est sans doute la forme qu'aurait prise XP, et qui garantit la propriété collective.
- Ensuite, grâce à l'alignement, il n'y a plus de discussions sur les équipes distribuées ou colocalisées. La question n'a plus de sens du fait que tout le monde travail ensemble, et que l'émergence d'outils de travail collaboratif virtuel aide (joinMe, HangOut, etc). Quelques équipes sont connues pour cela : l'équipe Cucumber, Corgibytes, etc.
Pour atteindre et renforcer le motif, Woody explique qu'il a introduit le strong pair programming, que Llewelyn Falco définit de la manière suivante :
Pour qu'une idée aille de votre cerveau à l'ordinateur, elle doit passer par les mains d'un autre.
Woody Zuill reste très modeste sur le Mob Programming : l'équipe avec laquelle il a travaillé a juste essayé des pratiques ; elle a augmenté l'utilisation des pratiques que les membres trouvaient positives. Woody a vu des "code smells" et a demandé à l'équipe comment améliorer leurs compétences techniques :
Les personnes faisant le travail sont le plus à même de savoir comment faire le travail.
Une journée type d'une équipe mob commence par une heure d'amélioration de pratiques de code, sans stand up. Après cela, l'équipe travaille sur le produit, pendant au plus huit heures par jour. Après une courte période, le Product Owner devient vite membre de l'équipe quasi temps plein. Il y a plusieurs principes à l'oeuvre :
- Turning up the good (Faire plus de ce qui est bon, NdT) : c'est ce qu'explique Kent Beck dans "XP Explained". Si quelque chose paraît donner un retour positif, faîtes en plus.
- Rétrospectives : pour avoir de meilleurs résultats, l'équipe analyse ses propres pratiques au moins une fois par jour pour s'adapter et turn up the good.
- Pratiques hebdomadaires : pour améliorer les compétences de code, il est nécessaire de pratiquer.
Robert Henri résume cela :
L'objet n'est pas de produire de l'art, c'est de rentrer dans cet état merveilleux qui rend l'art inévitable.
En conclusion, le Mob Pogramming s'articule autour d'une attitude tournée vers l'apprentissage : Partager / Faire attention aux idées des débutants.
Zuill ne promeut pas le Mob comme une "obligation", mais encourage des rétrospectives plus fréquentes et une attention sur l'équipe. De manière au moins aussi importante que les pratiques décrites ci-dessus, le Mob Programming sera par essence différent dans chaque équipe.
Toute personne dans une équipe mob est exposée, ce qui implique un degré requis de sécurité psychologique pour un bon fonctionnement. Ceci est très proche des explications sur les Core Protocols, que Richard Kasperowski présentait deux jours avant cette conférence. C'est sans doute pourquoi les Core Protocols, les Open Space et le Mob Programming peuvent servir de définition au Modern Agile.
Entretien avec Woody Zuill
InfoQ FR : Woody, merci pour cet échange avec InfoQ FR. Après votre présentation, vous expliquiez que l'industrie IT est cassée. Pourriez-vous développer votre idée ?
Woody : Je n'irais peut-être pas jusqu'à dire que l'industrie est cassée, mais beaucoup des pratiques que nous suivons le sont seulement par convention. C'est souvent comme le disait Adm. Grace Hopper : “Les humains sont allergiques au changement. Ils aiment dire "nous avons toujours fait cela de cette manière". J'essaye de me battre contre cela". Quand nous agissons seulement parce que "nous avons toujours procédé ainsi", je vois une opportunité d'amélioration.
InfoQ FR : Avec cette vision, d'après vous, quels sont les moyens d'améliorer la situation ?
Woody : Il est très important de faire attention aux choses qui marchent bien, puis d'expérimenter pour voir si nous pouvons trouver des manières d'amplifier ce qui est bon. Par exemple, avant de découvrir le "Mob Programming", nous nous étions rassemblés pour regarder le travail de quelques développeurs qui rencontraient des difficultés. Après avoir regardé les types de problèmes, nous avons commencé à travailler dessus durant la réunion. C'est-à-dire que plutôt que de suggérer des idées et retourner à son bureau travailler seul, nous avons tous commencé à travailler ensemble comme une équipe. Nous avons noté que c'était efficace et avons décidé de continuer à travailler de la sorte pour quelques jours comme expérience pour voir s'il était possible de faire plus de ce qui est bon et collaborer. Cela a superbement fonctionné, et c'est ce qui nous a conduit à travailler de la sorte, "Mob Programming", en tant qu'équipe, tous les jours.
InfoQ FR : En tant que héraut du Mob, comment introduiriez-vous le Mob Programming dans une entreprise ?
Woody : Même si j'ai confiance dans le fait que le Mob Programming a beaucoup d'avantages, je ne présuppose pas que les bénéfices observés dans certains contextes soient applicables universellement. Cependant, quand je suis invité à introduire le Mob Programming dans des équipes, je fais un atelier pour explorer la nature du développement logiciel, les bénéfices à travailler en équipe, et les techniques pour partager les idées et gérer respectueusement les opinions divergentes.
InfoQ FR : De l'autre côté, si nos lecteurs sont convaincus par le Mob Programming, quels conseils donneriez-vous pour introduire les pratiques depuis l'intérieur de l'équipe ?
Woody : Faites de petits pas. Si les gens sont intéressés par l'expérimentation du mob, je vous suggère de commencer par travailler ensemble sur de simples exercices ou des kata. Sans la pression d'un travail sur du code de production, vous pouvez pratiquer le travail ensemble et apprendre à bien interagir ensemble. C'est finalement le but du Mob Programming, apprendre à bien travailler ensemble.
InfoQ FR : Avec un peu de distance, pensez-vous que le Mob Programming puisse être utilisé sur autre chose que du développement logiciel, comme SCRUM ?
Woody : Comme avec l'Agile ou XP, le Mob Programming est centré sur le développement logiciel, mais des concepts similaires sont utiles avec d'autres activités, comme le design, le marketing, l'ingénierie hardware, la documentation, ou juste n'importe quoi. Bien travailler ensemble a des avantages dans de nombreux domaines.
InfoQ FR : Pendant un atelier avec des facilitateurs, vous disiez, et je vous cite : "It's not about Mob Programming". Donc si le sujet du mob n'est pas le mob, qu'est-ce que c'est ?
Woody : Le sujet est de découvrir les principes et pratiques qui sont importants dans votre contexte de travail, et les personnes avec qui vous travaillez. Le Mob Programming en soi est à peine plus qu'une évolution quand vous laissez les gens qui travaillent ensemble définir la manière de faire leur travail. Ceci s'est produit dans un environnement où nous nous exercions à obtenir de meilleurs résultats à partir de rétrospectives régulières et fréquentes, à faire attention à ce qui se passe bien, et faire plus de ce qui donne des bons résultats. Quand nous le faisons bien, nous trouvons le bon équilibre de pratiques pour n'importe quel contexte.
InfoQ FR : Si nos lecteurs veulent creuser leur compréhension du Mob Programming, que leur suggériez-vous de lire/regarder/écouter/faire ?
Woody : Il y a une video de 3 minutes sur youtube qui est un point de départ amusant et qui montre notre équipe d'origine travaillant en mode mob sur une journée de huit heures.
Nous avons aussi écrit un livre avec Kevin Meadows qui est disponible.
Il y a également beaucoup de vidéos de présentations données durant des conférences, tout comme des podcasts, et j'anime souvent des webinars gratuits sur le Mob Programming. Je suis de plus toujours ravi d'échanger en visio-conférence pour répondre à toutes questions.