Chaque équipe a un certain niveau de dysfonctionnement. Et c’est normal, car les équipes sont constituées d’êtres humains imparfaits. Dans son livre Les cinq dysfonctionnements d’une équipe, Patrick Lencioni identifie ces cinq dysfonctionnements fondamentaux :
- Absence de confiance
- Peur du conflit
- Manque d’engagement
- Évitement de la responsabilité
- Inattention aux résultats
Ces dysfonctionnements se construisent les uns sur les autres. Une équipe qui ne se fait pas confiance a peur d’admettre ses lacunes et ses erreurs. Des équipes comme celle-ci ne sont pas vulnérables les unes autour des autres. Cela conduit à une peur du conflit, où les idées ne sont pas débattues ouvertement et les mauvais comportements ne sont pas évoqués par peur d’offenser quelqu’un. Plutôt que de résoudre les problèmes sous-jacents, l’équipe éprouve une tension croissante qui se manifeste par des remarques agressives parfois passives.
Parce que les idées ne sont pas discutées ouvertement, il y a très peu d’adhésion des membres de l’équipe, et donc ils ne sont pas pleinement engagés dans des accords. Cela conduit à éviter la responsabilité, car il est difficile de tenir quelqu’un responsable d’une norme qu’il n’a jamais vraiment acceptée en premier lieu. Tout cela se traduit par une inattention aux résultats où l’équipe n’atteint pas ses objectifs les plus significatifs.
Dans cet article, j’aimerais examiner ces dysfonctionnements dans le cadre d’une équipe d’ingénieurs logiciels. Parce que croyez-le ou non, les ingénieurs logiciels sont aussi des êtres humains imparfaits.
Absence de confiance
Les ingénieurs logiciels doivent pouvoir se faire confiance. Cela inclut la confiance que les membres de votre équipe sont au top de leur travail et sur lesquels on peut compter pour faire leur travail à temps et correctement.
Lorsque les membres d’une équipe d’ingénieurs ne se font pas confiance :
- Les membres de l’équipe cachent leurs erreurs par peur
- Le chef d’équipe fait fréquemment un suivi avec les membres de l’équipe pour s’assurer que le travail est fait
- Le chef d’équipe sert de gardien qui examine toutes les demandes de fusion avant que le code ne puisse être fusionné
- Les membres de l’équipe deviennent protecteurs des zones de l’application logicielle dans lesquelles ils ont travaillé et n’aiment pas que quelqu’un d’autre touche leur code
Mais quand ils se font confiance :
- Les membres de l’équipe détectent rapidement leurs erreurs, en discutent ouvertement et les résolvent rapidement
- Chaque membre de l’équipe montre qu’il s’approprie son travail, demande de l’aide en cas de besoin tout en restant propriétaire de la solution et en veillant à ce que le travail soit fait
- Tous les membres de l’équipe examinent le code des uns et des autres, et le sceau d’approbation de tout membre de l’équipe sur une demande de fusion est suffisant pour permettre la fusion du code
- Tout membre de l’équipe peut travailler dans n’importe quelle partie de la base de code
Peur du conflit
Chaque équipe d’ingénierie logicielle a besoin d’une bonne quantité de conflits. Vous pourriez soutenir qu’une équipe parfaitement alignée et d’accord sur tous les problèmes n’a pas besoin de conflit, ce qui est techniquement vrai, mais je n’ai pas encore rencontré d’équipe comme celle-ci. Après tout, les ingénieurs sont connus pour être opiniâtres.
Lorsque les membres d’une équipe d’ingénieurs ont peur du conflit :
- Les membres de l’équipe ne soulèvent pas de problèmes de processus ou d’autres problèmes d’efficacité
- Les réunions d’équipe sont ennuyeuses et sans trop de discussions
- Les membres de l’équipe permettent aux comportements toxiques de ne pas être contrôlés
- Les personnes peu performantes font chuter l’équipe en faisant les mêmes erreurs encore et encore et en faisant perdre le temps des membres de leur équipe
- Le moral baisse
Mais quand le conflit est embrassé :
- Les membres de l’équipe cherchent toujours à améliorer leur façon de faire les choses et recherchent des processus obsolètes qui devraient être modifiés
- Les réunions d’équipe sont remplies de discussions animées et parfois de débats houleux (mais toujours en se concentrant sur des problèmes tangibles, pas sur des attaques générales les uns contre les autres)
- Les membres de l’équipe dénoncent les comportements toxiques et ne tolèrent aucune forme d’intimidation ou de violence verbale
- Les moins performants sont tenus responsables des normes de l’équipe et sont informés de la façon dont leur comportement affecte le reste de l’équipe
- Le moral augmente
Manque d’engagement
Les équipes d’ingénierie logicielle doivent s’engager à atteindre les objectifs qu’elles se sont fixés. Mais s’il n’y a pas de discussion honnête lorsque les objectifs sont fixés, il n’y a pas d’adhésion de chaque membre de l’équipe pour atteindre réellement ces objectifs.
Lorsque les membres d’une équipe d’ingénieurs font preuve d’un manque d’engagement :
- Les objectifs de sprint et les délais sont souvent manqués
- Les membres de l’équipe travaillent souvent sur les mauvaises choses
- Les normes de qualité du code ne sont pas respectées et des raccourcis sont pris
Mais lorsque chaque membre de l’équipe s’engage à atteindre les objectifs de l’équipe :
- Les objectifs de sprint et les délais sont généralement respectés (avec un retard occasionnel)
- Chaque membre de l’équipe travaille sur la chose la plus importante à un moment donné
- Les normes de qualité du code sont convenues et suivies (et appliquées par les formateurs de code, les linters et les suites de tests exécutés dans des pipelines d’intégration continue)
Évitement de la responsabilité
Les équipes d’ingénierie logicielle doivent faire en sorte que chaque membre de l’équipe respecte les normes auxquelles ils se sont mis d’accord.
Un évitement de la responsabilité découle en grande partie d’une peur du conflit. Il est important de se rappeler cependant que lorsque nous parlons de responsabilité, nous ne voulons pas dire punir quelqu’un chaque fois qu’il commet une erreur. Nous ne voulons pas non plus dire que vous devez être impoli à ce sujet. Vous pouvez demander des comptes à quelqu’un tout en le traitant avec respect.
Se tenir mutuellement responsable signifie avoir une discussion honnête et ouverte lorsque quelqu’un ne fait pas tout son possible ou entraîne l’équipe vers le bas. Ces conversations n’ont pas à attendre que les tensions s’intensifient jusqu’à ce que tout le monde soit à son point de rupture. Ils peuvent se produire immédiatement pour les plus petits comportements sous forme de micro-doses respectables de feedback. Être clair n’est pas être méchant.
Lorsque les membres d’une équipe d’ingénierie évitent de rendre des comptes :
- Les tâches importantes ne se font pas
- Les moins performants entraînent l’équipe vers le bas
- La vélocité globale de l’équipe diminue
- Les normes sont ignorées et la qualité du code diminue
- Le chef d’équipe ou le manager est le seul à s’occuper des mauvaises performances ou d’autres mauvais comportements
Mais lorsque les membres de l’équipe se tiennent mutuellement responsables :
- Les tâches importantes sont terminées
- Les moins performants sont encouragés à s’améliorer ou à passer à autre chose
- La vélocité globale de l’équipe augmente
- Les normes sont respectées et la qualité du code reste élevée
- Tous les membres de l’équipe se sentent à l’aise de se tenir mutuellement responsables, pas seulement le chef d’équipe
Inattention aux résultats
Les équipes d’ingénierie logicielle doivent se concentrer sur les résultats. Les ingénieurs n’accomplissent pas des tâches aussi occupées – ils construisent des choses pour offrir de la valeur à leurs clients et résoudre des problèmes.
Lorsque les membres d’une équipe d’ingénieurs font preuve d’inattention aux résultats :
- Les objectifs et les délais de sprint sont souvent manqués
- Beaucoup de travail peut être fait, mais ce peut être le mauvais travail ou un travail à faible impact
- Les membres de l’équipe ne montrent aucun intérêt ou propriété de leur travail
- Chaque membre de l’équipe semble aller dans une direction différente
Mais lorsque les membres de l’équipe montrent une grande attention aux résultats :
- Les objectifs de sprint et les délais sont généralement respectés (avec un retard occasionnel)
- Beaucoup de travail est fait, et c’est le bon travail, le travail le plus important
- Chaque membre de l’équipe montre qu’il s’approprie son travail et est fier de faire du bon travail
- Les membres d’une équipe travaillent vers un objectif commun et ne sont pas simplement une collection d’individus mais une équipe
Conclusion
Toutes les équipes présentent un certain niveau de dysfonctionnement, et c’est parfaitement normal. Mais si vous voulez vous améliorer en équipe, la première étape consiste à avoir une conversation ouverte et honnête sur ces dysfonctionnements. Identifiez les forces et les faiblesses de votre équipe et élaborez un plan pour vous améliorer.
Surmonter les cinq dysfonctionnements d’une équipe d’ingénieurs logiciels est incroyablement simple en théorie et pourtant très difficile en pratique. Et c’est exactement ce qu’il faut pour s’améliorer dans ce domaine : pratique, pratique, pratique.