Les personnes parlant et utilisant le Mob Programming sont peu nombreuses. Malgré cela, leurs expériences sont très riches du fait des perspectives divergentes qu'elles ont concernant les pratiques de codes et d'équipes.
Llewellyn Falco s'exprimait sur le sujet durant la première conférence sur le Mob Programming début mai 2016.
L'intervention de Llewellyn Falco, intitulée "Understanding the Science of Mobbing", part du principe que le Mob Programming n'est pas une science - tout comme l'informatique (computer sciences en anglais, NdR). Il y a pourtant des pratiques partagées sur la manière de développer des logiciels :
- Le Solo programming est sans doute la pratique la plus admise aujourd'hui, qui implique que tout ce qui est produit entre dans le code, le bon comme le mauvais.
- Le Pair programming est la seconde manière la plus connue de développer et les meilleures idées de chacun entrent dans le code.
- Le Mob Programming est enfin la dernière pratique, et sans doute la moins connue, et comme l'explique Llewellyn : ce n'est pas obtenir le plus possible des gens mais le meilleur.
Où est donc la science ? Llewellyn fait un parallèle avec la théorie des systèmes : une équipe forme un système. Et c'est un système complexe. Il est difficile d'en isoler une partie, ou pour paraphraser Dan North : "Quel est le son de l'applaudissement d'une main ?".
Démarrer quelque chose dans un système est comme allumer un feu de camp. Dans une équipe de développeurs autonomes, même les très bonnes, lorsque quelqu'un est bloqué, il reste coincé seul. Pour qu'une idée grandisse, comme pour le feu, il faut des brindilles, et en quantité. C'est le principe du Mob : disposer d'un ensemble de personnes pour nourrir une étincelle. Pour utiliser une image différente (qui ne vient pas de Llewellyn), c'est l'exact opposé d'un épisode de Docteur House (ou le dernier épisode de la saison 1 de Silicon Valley) : quelqu'un a une illumination, ou lance une idée, et le reste de l'équipe contribue pour la rendre meilleure. Cet impact est similaire avec la mémoire et la mémoire de groupe. Cette dernière est plus robuste que celle d'un seul esprit, et une bande peut déclencher des mémoires multiples. Il en va de même avec la résolution de problème : l'état de votre système favorise ce que Takeuchi et Nonaka appellent la "diversité". Et c'est un état nécessaire quand les choses tournent mal.
Llewellyn posa la question suivante, apparamment simple :
Comment construisez-vous une équipe ?
Il y a deux prérequis à la réponse :
- Dans une bande, vous ne savez pas d'où vienennt les idées, et ce n'est pas le sujet. Au contraire, la plupart du temps nous souffrons du biais du survivant : on regarde les éléments qui ont apporté le succès, plus que de renverser l'analyse. Par exemple, il est souvent dit que les dirigeants ont les meilleurs idées, parce que leurs idées sont suivies. Cependant, la plupart du temps, cela n'a rien à voir avec l'idée elle-même, surtout durant les réunions. Le sous-jacent est l'HiPPO (Highest Paid Person) : quand un directeur parle à une équipe et ne travaille pas avec elle, les mécanismes de succès sont différents. Pour le dire brutalement, si le projet est une réussite, ce sera grâce à l'idée du directeur ; autrement ce sera la faute de l'équipe.
- Ceci conduit à un autre point : l'effet Benjamin Franklin [EN]. Quand nous pensons que nous sommes agréable, aimable et respectueux avec quelqu'un, c'est en fait l'inverse : ce sont les personnes avec lesquelles nous sommes agréable, aimable et respectueux que nous apprécions.
La réponse complète à la question simple est donc :
En travaillant ensemble en tant qu'équipe. [...] Vous êtes la somme des personnes avec lesquelles vous êtes.
C'est à ce niveau que nous rejoignons l'humanisme : si une équipe est plus que la somme des individus qui la compose, et que nous représentons la somme des personnes avec lesquelles nous trainons, nous devons être agréable, aimable et respectueux. C'est le point de convergence avec le principe Lean Guider par l'exemple.
Le dernier point mis à mal par Llewellyn est la différence entre Dette Technique et Capital Technique. Penser en termes de coûts et oublier les capitaux est injuste (et plutôt facile quand vous cherchez à réduire les coûts et non à créer de la valeur).
Le mythe du développeur puissance 10 est de manière équivalente difficile à tuer. Mais un peu comme pour le "bon", à quoi ressemble un développeur puissance 10 ? Avec quelques exemples basés sur des cas mathématiques (que je ne comprends pas bien, je vous en fais donc grâce), sa conclusion est que souvent puissance 10 ne ressemble pas à ce que vous attendiez. Tout est histoire de perspective, et 10 fois plus rapide peut sembler très lent tout en étant super efficient.
Pour donner un peu de concrêt, Llewellyn introduit la différence entre deux concepts étranges :
- La Tâche Infinie, par exemple couper un gâteau en deux jusqu'à la fin des temps.
- La Super Tâche, qui est une tâche infinie avec une limite de temps. Par exemple couper un gâteau en deux en une minute, et couper la part restante en deux avec la moitié du temps. Le gâteau est fini d'être coupé en moins de deux minutes.
De là, et pour adopter une vision de direction, personne ne peut dire à quoi ressemble un investissement de 1% du temps de quelqu'un à apprendre. Par contre, si vous travaillez dans une grande entreprise (ou une ancienne peut être), il y a des chances que vous compreniez à quoi ressemble de ne pas avoir appris pendant 10 ans.
Pour finir sur le mob programming, l'attention principale porte sur la culture : pour atteindre une transformation, elle devrait tendre vers l'ouverture et l'invitation. C'est sans doute le point à garder de cette intervention comme une mise en abyme : vous devriez aller aux conférences en tant qu'équipe, avec cette culture de l'ouverture et de l'invitation. Autrement, en rentrant avec vos nouveaux concepts, l'équipe n'est plus en phase (et risque de vous repousser la plupart du temps).