C'est la faute à Raoul

Personne n’aime être la cible d’une accusation, qu’elle soit justifiée ou non. C’est encore plus vrai au sein d’une équipe. Et c’est encore pire lorsque cette accusation est proférée publiquement, devant une assemblée d’yeux accusateurs et réprobateurs. L’accusation est encore plus mal perçue lorsqu’elle est formulée gratuitement, sans aucun autre but que de trouver un coupable à une faute, simplement pour trouver un responsable. Or, dans un certain nombre de cas, trouver le fautif n’apportera rien de plus que de l’animosité, du ressentiment et de la honte. Rien de bien constructif. C’est ce qui est arrivé à Dave Lawper récemment.

Dave Lawper est membre d’une équipe de développement agile, travaillant actuellement sur un sprint d’évolution d’une application. Par un malheureux concours de circonstances, il s’est récupéré une des dernières histoires du sprint, toutes les autres ayant été affectées aux autres membres de l’équipe. Pas de chance pour notre pauvre Dave Lawper, cela concerne un module applicatif qu’il ne maîtrise pas. Qu’à cela ne tienne, il se retrousse les manches et plonge la tête la première dans le code.

Au bout de plusieurs jours, il n’a pas vraiment avancé. Il a une meilleure connaissance de l’existant, mais il n’a toujours produit aucun livrable. La fin du sprint est très proche, et l’Assurance Qualité réclame une livraison pour pouvoir terminer à temps le sprint. Dave Lawper promet de se dépêcher, et met les bouchées doubles pour avancer plus vite. Il sent qu’il ne pourra pas parvenir à un résultat convenable dans le temps imparti. Il n’a pas le choix, il décide de fournir un hack au prix d’une dette technique. Il livre dans les temps.

Trois mois plus tard, alors que plusieurs sprints se sont écoulés depuis cette mésaventure, Deb Lopez récupère une histoire qui doit faire évoluer le code produit il y a bien longtemps par Dave Lawper. Elle peste contre ce code de très mauvaise qualité, et se plaint qu’il faut tout réécrire. Rien n’est réutilisable, tout est bon pour la poubelle. Après une rapide inspection de l’historique du gestionnaire de version, on découvre l’auteur de ce code : Dave Lawper.

Lors de la rétrospective de sprint, Herman Adger lui reproche devant toute l’équipe son manque de discernement. Le manager l’accuse publiquement de ne pas avoir été à la hauteur et d’avoir fait de la mierda. A cause de lui, Deb Lopez a perdu un temps fou pour effectuer un refactoring en profondeur. Ce retard a empêché l’équipe d’achever toutes les histoires du sprint dans le temps imparti. Herman Adger affirme que l’équipe risque de se traîner une réputation de manque de fiabilité et d’efficacité. “On va encore dire que le dév ne sait pas livrer à l’heure”, lui assène-t-il même devant les visages fermés mais non moins réprobateurs de ses semblables.

Excellent. Herman Adger a pu trouver un coupable, pour se dédouaner de la responsabilité de l’erreur qui incombe, dans les faits, à toute l’équipe. Toute l’équipe ? Toute l’équipe, oui. Dave Lawper a fait ce qu’il fallait. Il a fait ce qu’il fallait pour livrer l’histoire. Il ne pouvait rien faire de plus. En revanche, les autres membres de l’équipe et Herman Adger auraient dû prendre en compte cet emprunt de dette technique, et agir en conséquence pour rattraper le tir au sprint suivant.

Herman Adger a préféré accuser. Accuser, c’est facile. Ça soulage. Mais à quoi ça sert ?

Au final, personne n’en tire aucun bénéfice. La culpabilité n’aidera certainement pas Dave Lawper à mieux faire la fois suivante. Dans le meilleur des cas, il se débrouillera pour ne plus jamais se retrouver dans cette situation, préférant jouer l’anguille et se faufiler entre les balles plutôt que de prendre des risques. En généralisant ce point, plus personne n’osera s’attaquer à des chantiers risqués ou difficiles. Mince alors. L’application risque de stagner méchamment. L’inquisition publique n’est peut-être pas la meilleure solution, alors.

Accuser un individu dans une équipe, c’est le moyen idéal pour semer la discorde et rompre la cohésion. L’équipe se scinde en trois parties : l’accusé, l’inquisition et le jury qui partagera plus ou moins l’avis de l’accusateur. Or, une équipe est censée composer un ensemble indissociable, oeuvrant main dans la main constamment pour avancer dans la même direction. Clairement, ce n’est pas le cas ici.

Mais alors, que faire ?

Raoul a la solution. Ou plutôt Raoul est la solution. Vous avez besoin d’un coupable ? C’est lui. Le coupable idéal. Il est personne et tout le monde. Il n’est personne de précis dans l’équipe. Il est un anonyme collectif représentant tout le monde et personne. C’est contre lui qu’il faut reporter tous les griefs.

Mais à quoi ça sert ?

Vous éviterez la crémation de la sorcière sur la place publique face à un attroupement de pécores avides de jeter eux aussi des poignées de purin fraîchement récolté. Personne dans l’équipe ne pourra s’agacer de la énième erreur de son semblable, et faire ainsi naître (ou pire, croître) la tension qu’il pourrait exister entre eux. Le phénomène d’opposition disparaît, et vous conservez ainsi la cohésion de l’équipe face à un ennemi fictif.

Sauf que ton Raoul, là, il n’existe pas.

Oui, il n’existe pas. C’est quelqu’un dans l’équipe. Ou en dehors de l’équipe. On ne le sait pas, et on ne veut même pas le savoir. Seul le résultat de l’erreur compte. De ce fait, ce qui importe n’est plus qui est à la source de l’erreur, mais quoi. En ce sens, la conversation pourra être orientée non pas vers la recherche d’un coupable, mais plutôt vers la recherche d’une solution (voire d’un moyen de l’éviter à l’avenir). Toute l’équipe pourra y réfléchir ensemble, et tous pourront apprendre quelque chose à cette occasion.

En bonus, le coupable se reconnaîtra sans pour autant se manifester, et il montrera un intérêt redoublé pour se corriger.

Vous avez donc deux effets : vous maintenez la cohésion dans l’équipe en éliminant les risques d’affrontements, et vous faîtes profiter l’ensemble des collaborateurs des enseignements de la solution. Dans un cas optimal, c’est l’équipe entière qui se focalisera sur la recherche de la solution.

Si l’équipe de Herman Adger avait suivi ce principe, Dave Lawper n’aurait pas été au centre de l’attention à devoir subir les remontrances. Raoul aurait été le coupable de tous les maux, et l’équipe aurait ensuite pu se focaliser sur la recherche d’une solution, comme par exemple :

• L’équipe aurait dû répondre présente quand Dave Lawper a demandé de l’aide
• L’équipe aurait dû accepter le hack pour effectuer une livraison rapide et fonctionnelle, et prendre en compte le temps nécessaire à la réécriture de ce hack lors de son évolution.

Tout se serait passé en douceur, l’équipe n’aurait pas eu à souffrir d’un retard au dernier sprint et aurait pu continuer à naviguer sur une mer d’huile en toute quiétude. La rétrospective de sprint aurait été bien moins douloureuse, et bien plus productive.

Et vous, quand allez-vous adopter Raoul ?

PS : Je suis sincèrement désolé pour tous les Raoul présents dans vos équipes de développements. Je vous propose une liste de prénoms non exhaustive dans laquelle vous pouvez piocher allègrement : Euzèbe, Raymonde, Roger, Auguste, Thérèse, Augustin, Artistide, Marcel, Robert, Gilbert, Kévin, René-Henri-Jean-Charles.

Servez-vous, ils sont libre de droits, même pour une utilisation commerciale !