Ceci n'est pas tiré de faits réels même si - malgré mes efforts pour anonymiser les personnages (qui existent) et la situation (qui a existé), il se peut que quelques passages puissent démontrer le contraire. Bien malgré moi, vous en conviendrez.

La situation : le back-office from hell

On est sur un besoin urgent de développer un dashboard admin assez critique pour une opportunité qui ne restera pas une opportunité bien longtemps.

Le back-end commence à ressembler à quelque chose, mais on a totalement délaissé la question de l'admin pour répondre à des enjeux métier un peu pointus.

Vient le moment d'étudier la question, et c'est le drame.

Robert tient absolument a lancer un projet Remix.js (il a lu un post LinkedIn qui dit que c'est l'avenir), Bob pense qu'on va gagner du temps avec Forest Admin, Josianne pense qu'on pourrait réunir le meilleur des deux mondes avec React Admin

(spoiler : les protagonistes qui n'existent pas réellement sont effectivement partis sur cette dernière solution, mais non sans passer par un long processus qu'on va détailler tout de suite)

Tout en continuant d'avancer sur le back-end, chacun rumine dans son coin et les daily deviennent assez tendus. Tout ça commence à prendre des airs de règlement de compte, et c'est le sprint en cours qui fini par en patir.

Comment gérer ça de façon pro tout en gardant votre santé mentale (et en essayant de sauver tout le monde) ?

Est-ce un avion ? Un oiseau ? Non !!! C'est le scrum master qui se jette par la fenêtre !

1. Retrospective spéciale

Première étape : organiser une session dédiée à la résolution du conflit. Pas une de ces réunions interminables où tout le monde finit par vouloir partir et mettre son profil LinnkedIn à jour, mais un vrai moment d'échange constructif.

Faites exprimer chaque point de vue avec un timebox strict (vous aurez du "oui mais au moins on maitrise totalement le développement" ou encore du "oui mais on va gagner du temps")
Utilisez des post-its (virtuels si vous êtes en remote) pour mapper les pour et contre de chaque solution en demande à chacun d'être objectif (et en recadrant si c'est nécessaire)
Gardez une trace écrite des décisions, et demandez à chacun de confirmer ce qui a été dit

2. Plus toi, plus moi, et puis l'autre aussi même s'il sent pas très bon en arrivant au bureau le matin

Le truc primordiale, c'est d'essayer de faire comprendre à chacun que l'on est dans une quête collaborative :

Proposez éventuellement des spikes pour tester rapidement chaque solution (si vous en avez la possibilité dans le temps alloué. Pour ce projet fictif, on n'a pas eu le temps)
Définissez des critères d'évaluation objectifs (coûts, maintenabilité, temps de développement)
Transformez la confrontation en exploration technique constructive
Demander à chaque contradicteur d'exprimer des arguments clairs et objectifs fasse à la proposition en face de lui, et challengez sa propre proposition en face

3. Du consensus

C'est bien beau mais le chrono tourne, et il faut bien prendre une décision.

L'objectif, au final, n'est pas forcément de privilégier une solution plus qu'une autre, surtout si chaque solution a du sens.

L'objectif, c'est de faire consensus et de permettre à chacun de s'approprier la solution retenue (comment je peux intervenir collaborativement sur ce choix)

Si vous avez du mal à obtenir un consensus, vous pouvez :

Utiliser une matrice de décision avec des critères pondérés
Faire voter l'équipe (certains préconisent le vote anonyme, moi je pense que chacun doit prendre ses responsabilités pour éviter un climat de suspicion)
Que vous soyez CTO, Tech Lead, Lead dev, dev senior, dev junior ou je sais pas quoi, votre vote = 1

C'est le business qui compte, pas la techno

On a tous connu ça : prise de tête en mélée avec une partie de l'équipe parce 2 d'entre eux veulent du Next, 1 veut du Remix, 3 autres veulent se pendre

Si on prenait un peu de recul, on pourrait peut être réaliser que :

La plupart du temps, la techno, le client final s'en fout (le PO et CEO aussi, mais ils préfèrent vous faire croire le contraire)
Si on prenait plus de temps à créer de la valeur qu'à se battre pour savoir si on va utiliser HeadlessUI ou Ant Design, chacun gagnerait au change
Si la boite perd une belle opportunité à cause d'une bataille d'égo, soyons réalistes : il y aura des conséquences

Les conflits, ca fait grandir

La gestion et la résolution des conflits, c'est pas ce qu'il y a de plus fun, mais c'est nécessaire pour votre équipe.

L'essentiel est de garder son calme, de structurer la discussion, et de transformer le conflit en opportunité d'amélioration. Si chacun se sent respecté pendant tout le processus, c'est toute l'équipe qui en sortira plus forte.

Et puis si jamais y a vraiment rien qui marche, vous pouvez toujours acheter une pelle et de la chaux.

Articles

Guide de survie du Scrum Master en milieu (un peu) hostile : résoudre les conflits autrement qu'avec un marteau