BLOGUE
Vous êtes-vous déjà demandé ce qui est arrivé en premier : l’œuf ou la poule? On pourrait se poser la même question pour la sécurité psychologique et la programmation en groupe ou en binôme. En effet, ces concepts se nourrissent mutuellement pour améliorer le travail des équipes de développement logiciel. Dans cet article de blogue, apprenez-en davantage sur le pair programming et le mob programming, ainsi que la relation bénéfique qu’ils entretiennent avec la sécurité psychologique et la performance des équipes.
Revue de concepts
Avant d’entrer dans le vif du sujet, quelques définitions pour mieux comprendre la suite des choses :
Pair programming
Le pair programming (ou programmation en binôme) signifie que deux personnes écrivent du code ensemble sur un ordinateur. C’est une méthode de travail très collaborative qui implique beaucoup de communication. Lorsqu'une paire de développeurs travaille ensemble sur une tâche, ils ne se contentent pas d'écrire du code : ils planifient et discutent également de leur travail. Ils clarifient leurs idées en cours de route, discutent des approches et trouvent de meilleures solutions.
Mob programming
Le mob programming (ou programmation en groupe) est une approche du développement logiciel dans laquelle toute l'équipe travaille sur la même chose, au même moment, dans le même espace et sur le même ordinateur. Cette approche étend le concept de programmation en binôme à l'ensemble de l'équipe, qui collabore en permanence sur un seul ordinateur pour fournir un seul élément de travail à la fois.
Sécurité psychologique
La spécialiste du comportement organisationnel Amy Edmondson de l’université Harvard a été la première à introduire le concept de sécurité psychologique, qu'elle a défini comme «la conviction partagée par les membres d'une équipe que celle-ci ne présente aucun danger pour la prise de risques interpersonnels». Les chercheurs de Google ont quant à eux identifié que, parmi les cinq dynamiques clés des équipes efficaces, la sécurité psychologique était de loin la plus importante. Ils ont constaté que les membres d'équipes présentant une plus grande sécurité psychologique sont plus susceptibles d'exploiter la puissance des diverses idées de leurs coéquipiers et qu'ils sont jugés deux fois plus efficaces par les gestionnaires.
Pourquoi adopter la programmation en binôme ou en groupe?
Étant très impliqué dans la communauté du développement logiciel, j’aime essayer les nouveautés de l’industrie et m’informer sur leurs avantages. Le pair et le mob programming m’ont interpellé puisque ce sont des méthodologies qui répondent à des problèmes réels du développement logiciel. Ils permettent d’éviter certaines frictions courantes en changeant notre façon de travailler. Deux exemples fréquents me viennent en tête :
- J’ai une merge request en attente et je dois relancer mes collègues pour des approbations.
- Je n’aime pas recevoir des commentaires sur un travail fini pour des détails.
Le problème de ces situations est que toute la rétroaction se fait après. On peut facilement se mettre dans la peau des développeurs et comprendre qu’ils n’aient pas envie de retoucher à une tâche complétée ou d’attendre une approbation pour avancer. La solution : faire une rétroaction plus rapide pour éliminer la friction. Et la meilleure façon de donner une rétroaction rapidement est de le faire en même temps qu’on écrit le code!
Les boucles de rétroaction rapide ne sont pas nouvelles dans le monde du développement logiciel, mais on met souvent l’accent sur les clients et les utilisateurs, alors que les développeurs aussi peuvent en bénéficier. En ayant quelqu'un à côté pour nous poser des questions, on peut discuter et justifier les décisions auprès d’un pair sans devoir reprendre une tâche du début. On fait la revue de code en temps réel! Cette façon de travailler permet aussi aux commentaires d’avoir plus d’impact et aux développeurs de se réaligner sans perdre de temps.
Travailler en binôme permet de donner une rétroaction en temps réel
Comment pivoter vers le pair ou le mob programming?
Puisqu’il faut bien commencer quelque part, il faut savoir qu’il y aura une courbe d’apprentissage à implanter cette nouvelle méthode de travail. L’important c’est de l’essayer en acceptant que ce ne soit pas parfait du premier coup. Le pair et le mob programming sont des expériences qui en valent la peine si l’on se donne le temps d’itérer et de raffiner notre façon de faire. Idéalement, commencez avec quelqu'un qui en a déjà fait afin d’avoir une bonne première expérience et apprendre ce qu’est la vulnérabilité en pair programming.
De plus, il faut oublier l’idée reçue selon laquelle travailler à deux développeurs sur un ordinateur n’est pas productif. Si l’on considère toutes les interventions asynchrones lorsque chacun travaille sur une tâche, les développeurs peuvent travailler un nombre d’heures similaire même s’ils ne le font pas en simultané. Au moins, avec le pair et le mob programming, on maximise le résultat, même s’il y a un peu moins de tâches «cochées» à la fin du sprint.
Zoom sur l’outcome (résultats) plutôt que l’output (tâches terminées)
Le pair programming optimise les séquences de travail : une story passe de to do à done très vite, sans bloquants. L’équipe a moins de travail entamé (WIP), mais livre de la valeur plus rapidement. Chez Nexapp, on est d’avis que tant qu’il n’y a rien de livré, il n’y a pas de valeur. Un WIP élevé n’est donc pas nécessairement un signe de productivité si chacun travaille sur des tâches qui bloquent en revue ou en QA. C’est un pensez-y-bien!
Aussi, les storys livrées en pair ou en mob programming sont d’un niveau de qualité élevé puisqu’elles ont bénéficié du génie logiciel de plusieurs développeurs qui se sont entendus sur les requis, se sont remis en question et en ont discuté en long et en large. La probabilité de rendre un excellent résultat est beaucoup plus grande qu’en travaillant seul.
Quel est le lien entre le pair programming et la sécurité psychologique?
La vulnérabilité est à la base de la sécurité psychologique. Prendre un risque autour des membres de votre équipe peut sembler simple, mais poser une question de base comme «quel est l'objectif de ce projet?» peut donner l'impression que vous n'êtes pas au courant de vos dossiers. Il peut alors sembler plus facile de continuer à avancer sans demander de clarification afin d'éviter d'être perçu comme ignorant.
Pour travailler sur un écran partagé avec un collègue, il faut savoir se rendre vulnérable, car on ne peut pas se cacher.
Le pair programming et la sécurité psychologique font partie d’une boucle sans fin qui amène les développeurs à travailler de façon plus humaine et efficace. Plus un développeur est capable d’être vulnérable, mieux il travaillera en pair programming ou en groupe, et plus il sera en mesure de se rendre vulnérable … et ainsi de suite!
De plus, l’un des facteurs de succès du pair et du mob programming est la vulnérabilité. Les coéquipiers doivent accepter qu’ils aient chacun leurs forces et leurs faiblesses et que tout le monde ne contribue pas de la même façon. C’est ce qui permet de bâtir une équipe multidisciplinaire qui performe bien : lorsque chacun met ses forces de l’avant et comble ses faiblesses avec l’expertise de l’équipe pour s’améliorer.
Comment favoriser et maintenir la vulnérabilité dans l’équipe?
Ça prend une première personne reconnue pour son expertise, idéalement un leader, qui accepte de dévoiler qu’elle ne connaît pas tout. À ce moment, les autres membres de l’équipe qui voient une personne qu’ils admirent se rendre vulnérable seront portés à le faire à leur tour. La vulnérabilité peut devenir contagieuse et se propager rapidement dans une bonne culture d’entreprise qui ne fait pas dans le jugement.
Un autre ingrédient important est la bienveillance. Adaptez un rythme qui convient à la composition de l’équipe. Il faut parfois ralentir pour aller plus vite et le pair programming en est un bon exemple. Je conseille aux équipes de développement de prendre le temps de s’assurer que tout le monde comprend comment et pourquoi on travaille d’une certaine manière, parce que les développeurs qui ne sont pas à niveau d’une part ralentissent l’équipe (et continueront de le faire si l’on ne prend pas le temps de leur expliquer les méthodologies), et d’autre part ont le potentiel de devenir nos meilleurs joueurs pour éventuellement aller plus vite.
Il faut éviter de penser à court terme pour privilégier le bien-être de l’équipe à long terme. Prenons une équipe de hockey : si deux joueurs sur cinq ne savent pas patiner, l’équipe sera toujours en infériorité numérique. Les joueurs étoiles doivent apprendre à faire abstraction de leur productivité personnelle pour jouer en équipe.
Enfin, pour favoriser la vulnérabilité, les meilleurs leaders seront ceux qui donnent l’exemple, acceptent de ralentir, incluent tous les talents et se montrent vulnérables. Les leaders qui adoptent une vision de coaching peuvent aider les développeurs à trouver leur place et prendre confiance en leurs capacités.
Le mob programming permet aux équipes de développement de prendre des décisions ensemble pour mieux avancer
Rétroaction et sécurité psychologique
Avec la programmation en binôme ou en groupe, les développeurs s’habituent à recevoir des commentaires positifs, négatifs et constructifs dans le but de devenir encore meilleurs. Il est aussi plus facile d’assimiler les commentaires lorsqu’ils sont faits pendant la tâche qu’après.
En effet, recevoir une rétroaction après avoir accompli une tâche peut donner l’impression au développeur de passer un examen : on remet un travail, on passe à autre chose, puis on reçoit une note plus tard quand on a déjà commencé à oublier la matière.
En recevant la rétroaction pendant le développement, on peut s’expliquer, se remettre en question et se demander pourquoi on travaille d’une certaine façon. Le développeur peut ainsi comprendre pourquoi il doit apporter des modifications et les faire en temps réel plutôt que de recommencer parfois à zéro.
Il se peut aussi qu’en discutant on trouve une nouvelle solution, encore meilleure que la solution que chacun apportait au départ. La discussion a beaucoup d’importance et quand on fait ce processus de manière asynchrone, il n’y a pas cetéchange.
D’autres avantages du pair et du mob programming
- Partager ses idées plus souvent (et être en contact avec de nouvelles idées!)
- Apprendre à faire des compromis en équipe
- S’entendre sur les bonnes pratiques de travail
- Faire perdurer les connaissances dans l’équipe
- Éliminer la peur de perdre un joueur (et qu’on ne sache pas comment maintenir son code!)
- Partager la pression des échéances en groupe
- Favoriser la collaboration entre les membres de l’équipe
- Établir un filet de sécurité pour l’équipe
- Améliorer la proximité et la bienveillance entre les membres de l’équipe
- Réfléchir plus souvent au pourquoi derrière nos actions
- Verbaliser les automatismes développés avec l’expérience
Et tous ces bénéfices non tangibles contribuent grandement à la productivité!
Devrions-nous travailler en binôme tous les jours?
Pour toutes sortes de raisons, il n’est pas possible de faire du pair programming 100% du temps. Par exemple, certaines personnes ont besoin d’être seules de temps à autre pour leur santé mentale ou encore une tâche spécifique se sépare bien et l’on ne ressent pas le besoin de la travailler en groupe. Cependant, je recommande le pair programming dès qu’il y a un flou sur les requis, un besoin de discuter en équipe ou des hésitations sur le chemin à prendre.
Que votre équipe travaille en solo, en binôme ou en groupe, la tendance est à la collaboration en développement logiciel. Combinée à un environnement sécuritaire psychologiquement, la collaboration ne sera que le début vers de meilleures performances de livraison logicielle.
Avez-vous essayé le pair ou le mob programming? Que faites-vous pour favoriser la sécurité psychologique au sein de votre équipe? Je suis curieux de vous entendre et d’en discuter avec vous!