Au sein d’une équipe qui réalise du logiciel, il est indispensable d’avoir des conflits d’idées, car cette équipe cherche activement la meilleure solution (réalisable dans les meilleurs délais, étant donné l’information dont elle dispose et les incertitudes qui cernent son projet) et il est très rare qu’une solution consiste en la réunion de toutes les idées du groupe sagement combinées dans un pur esprit de consensus. Une équipe qui est en sécurité – donc où chacun peut être vulnérable, c’est à dire ouvert – peut exposer, étayer et résoudre 10 conflits d’idées par semaine et s’en trouver parfaitement indemne de toute meurtrissure, voire même enthousiaste pour son projet, qui avance.

Il n’en va pas de même au sein de l’entreprise, où la tolérance aux conflits d’idées est pour ainsi dire quasi-nulle. En grandissant l’entreprise a développé des spécialisations, qui se sont inévitablement cristallisées en silos. Les silos créent leur propre barrières de communication : interprétations, malentendus, parti pris, esprit de corps. Ces barrières, ajoutées au fait qu’une entreprise, ça se dirige, mènent bien souvent à des conflits de territoire, c’est à dire à des luttes de pouvoir.

Revenons à notre éditeur : pendant que l’équipe QA munie de sa nouvelle mission : assurer la couverture de tests auto de l’ensemble du produit, s’essaye à défier les lois de la physique (le temps objectif s’écoule à la même vitesse pour tous les acteurs d’un projet situés sur la même planète), le conflit de ressource stratégique qu’on lui a transféré, évolue insidieusement vers un combat de position.

Le QA lead, au bout d’une longue et frustrante “campagne de test” a tiré la première salve, en déclarant par email à destination des devs, CC 2 niveaux hiérarchiques :

Ce matin nous avons saisi 12 tickets intitulés “NPE”. On est au point où le produit est trop buggué pour être testable. Ce serait bien de relire un peu votre copie avant de déposer n’importe quoi sur RE7.

Ce à quoi le DEV lead, vexé dans l’amour propre de son silo (cette équipe logicielle tente en effet d’exister à travers plusieurs silos) a répondu :

On a tous beaucoup de travail. Si tu pouvais faire le tien sans trop polémiquer ça nous aiderait bien.

L’affaire est rapidement repassée de l’écrit à l’échange verbal, dans le bureau du CTO.

Le CTO se veut conciliant. Son QA lead n’a pas tort : les développeurs doivent commencer à vérifier leur code si on veut avancer plus vite. D’ailleurs ils sont les mieux placés pour écrire des tests unitaires.

Le DEV lead, qui est là depuis l’origine et a donc vécu les années héroïques, a préparé son argumentaire :

  • le test, ce n’est pas le métier du DEV.
  • cette mode du TDD, ça ne marchera pas ici. On est différent.
  • (innuendo) si ça doit devenir la stratégie, je préfère mettre les voiles.

Le CTO apaise la discussion. Il savait avant même d’arriver que le DEV lead brigue le poste de CTO. Mais ça n’aura pas lieu. Plus maintenant.

Stay Tuned

conflict-politics

Stay Tuned ! Publié sur Linked In le 16/09/2024