Blog

Une erreur est survenue dans votre équipe et soudainement tout le monde devient tendu et nerveux. La pression monte. Vite, il faut expliquer cette erreur, mais surtout, trouver qui est le ou la pauvre qui l'a commise!

La discussion prend rapidement une tournure désagréable. Chacun est sur la défensive, autant envers ses collègues qu'envers lui-même. On se dit, "j'espère vraiment que ce n'est pas ma faute, cette fois-ci, parce que c'est vraiment grave!" Ou encore "oh non, cette fois-ci c'est clairement ma faute. Comment je vais me sortir de celle-là?"

Multipliée par le nombre de personnes dans l'équipe, cette tension envenime rapidement les échanges. Certes, on cherche toujours la cause de l'erreur, mais il s'agit plutôt de trouver qui en est la cause. Une fois ce fait établi hors de tout doute, on peut ensuite passer à autre chose, réconforté dans la perception qu'on n'a rien fait de mal. Sauf bien sûr pour la personne à qui l'erreur est attribuée, qui elle passera forcément une assez mauvaise journée.

Pourquoi blâmer?

La tactique n'est pas nouvelle: chercher un bouc émissaire est une stratégie millénaire, visant principalement à sauver la face, à préserver notre image auprès des autres (et, dans une certaine mesure, même de nous-mêmes). Il apporte aussi une certaine perception d'efficacité et de simplicité: la cause a été entendue, le coupable trouvé et jugé. On peut alors clore le dossier et se mettre en mode solution.

Dans un contexte de travail d'équipe et de collaboration, cependant, l'impact de cette approche sur le climat, la transparence et l'efficacité de l'équipe se fait rapidement sentir. C'est dans cette optique que s'inscrit l'approche du blameless post mortem, visant à outrepasser le réflexe de la recherche de coupables pour arriver à un dénouement plus sain pour tous.

Un cas de figure: version blâme

Le petit nouveau dans l'équipe a oublié de tester un bout de fonctionnalité et a causé une panne majeure qui a impacté plusieurs clients déjà un peu échaudés par les problèmes de la semaine précédente. L'erreur est flagrante, le code ne fonctionne tout simplement pas dans la page en question, qui donne une erreur spectaculaire dès l'ouverture. Le développeur sénior qui a rapidement repris le problème l'a corrigé en 5 minutes, donc au moins, il n'y a pas eu de dommages plus grands.

Verdict: notre petit nouveau n'a pas encore fait ses preuves. Il faut lui rappeler de bien tester tous les pans de fonctionnalités qu'il touche. Pour quelques temps, peut-être qu'il faudrait que quelqu'un vérifie bien ce qu'il fait, parce que visiblement il ne comprend pas tout.

Résultat:

Le problème a été corrigé rapidement
L'équipe rechigne parce qu'elle a l'impression qu'elle devra passer derrière le fautif dans le futur, ajoutant à leur charge de travail
Le fautif se sent vraiment, mais vraiment incompétent et doute de ses capacités. Il prendra beaucoup plus de temps à l'avenir, et posera plus de questions pour être vraiment, mais vraiment certain de ne pas revivre ça.

Le même cas de figure: version sans blâme

Après avoir rapidement réglé le problème (c'est quand même la priorité!!), mais avant de passer au verdict, l'équipe tente de mieux comprendre ce qui s'est passé. Elle pose des questions:

Pourquoi la page n'a pas été testée? Réponse: le nouveau ne savait pas qu'elle existait, et personne ne semblait disponible pour l'aider lorsqu'il a travaillé sur la tâche.
Pourquoi l'erreur n'a pas été trouvée au code review? Réponse: le sénior qui l'a fait n'a pas remarqué qu'il manquait un bout de code.
Pourquoi le nouveau ignorait qu'une fonctionnalité aussi important existait? Réponse: l'équipe a peut-être oublié de lui en parler dans son introduction au produit.

L'objectif devient de connaître le contexte de l'erreur, puisqu'elle n'arrive jamais en vase clos.

Verdict: notre petit nouveau a fait ce qu'il pouvait avec les informations qu'il détenait. L'équipe a manqué de vigilance à la révision, et d'encadrement avec notre nouveau.

C'est un constat plus nuancé, ce qui est déjà une bonne étape. Mais l'équipe n'arrête pas là: elle cherchera des moyens pour éviter qu'une telle erreur se reproduise. Contrairement au blâme, elle a, dans ce cas-ci, du pouvoir sur les éléments à améliorer.

Elle peut s'assurer que tous les développeurs de l'équipe ont eu une présentation des fonctionnalités. Elle peut rappeler l'importance du code review dans le processus de qualité. Elle peut trouver un moment où le nouveau pourra "déranger" ses pairs avec des questions. Peut-être lui assigner une personne-ressource pour l'accompagner.

Résultat:

Le problème a tout de même été corrigé rapidement.
L'équipe comprend qu'elle a sa part de responsabilité et connaît les moyens de s'améliorer.
Le fautif se sent un peu mal d'avoir causé le problème, mais apprécie le fait que l'emphase n'est pas mise sur ce point. Il remarque que ses collègues se soutiennent quand quelque chose de grave se produit et ça le rassure.

L'impact sur la culture de l'équipe

Dans une équipe où le blâme est accepté, il finit par plomber la culture de plusieurs façons:

Les gens commencent à moins mettre de l'avant les problèmes qu'ils perçoivent avoir causés, voire à les cacher.
La performance diminue, parce que chacun sur-vérifie chaque chose qu'il fait.
Un climat de méfiance peut s'installer. Par exemple, soumettre son code en review devient tendu et stressant. Après tout, la personne qui fait la révision a le pouvoir de déceler un problème et de nous le reprocher.
Il peut se créer des divisions dans l'équipe, entre ceux perçus comme bons et ceux qui font des erreurs plus souvent.

Dans un tel climat, il devient difficile pour l'équipe d'aborder ouvertement les problématiques, ce qui est à la base d'une culture d'amélioration continue. L'équipe aura donc tendance à stagner.

Pistes de solutions

La bonne nouvelle, c'est que le blâme est un comportement. Il est donc plus facile d'intervenir sur ce comportement et amener un changement dans l'équipe. Les moyens exacts dépendront bien sûr du contexte particulier de votre équipe, mais il existe certaines valeurs sûres:

Intervenir dans les situations de groupe où une personne blâme directement une autre. Souligner le fait qu'il n'y a rien de constructif à chercher un coupable.
Encourager la discussion suite aux incidents et la guider vers la recherche du pourquoi plutôt que du qui.
Faire appel à l'empathie: tout le monde a déjà commis des erreurs et personne n'aime être montré du doigt.

La culture du blâme est l'une des dysfonctions possibles dans une équipe que Umaji peut travailler avec vous. Il est parfois étonnant de constater l'impact sur le bien-être et la performance des membres d'une équipe après des ajustements ciblés à la culture de travail. Si le sujet vous rejoint, n'hésitez pas à nous contacter!