Que pouvons-nous faire lorsque notre équipe se trouve dans un conflit ?

Nous pourrions ne rien faire, et voir ce qui se passe. Wait and Assess (Don’t look up). Il va se passer quelque chose rapidement.

Nous pourrions tenter de masquer le conflit, de le transférer, de créer une distraction. Ces manœuvres vont lui donner plus de force, et le transmuter avec plus de vigueur d’un conflit d’idées à une bataille de territoire.

Par exemple, chez cet éditeur qui se débat avec son produit legacy, une partie des DEVs pratique une forme d’écriture de tests auto (en débattant souvent de la bonne granularité) tandis qu’une autre partie admet ne pas s’en préoccuper du tout. C’est un conflit (d’état de l’art, donc d’idées).

Pourquoi pas ? Chacun son standard après tout.

Mais un jour, quelqu’un introduit un défaut dans du code non vérifié (car plusieurs standards = standard garanti nulle part).

Ou bien un jour, quelqu’un réalise qu’il doit d’abord modifier des tests pour modifier une simple fonction, et se met en retard !

Ou bien un jour, quelqu’une se dit qu’elle en a assez d’écrire des tests pour les autres.

Un indicateur très sûr (quoique tardif) de la présence d’un conflit, c’est que vous pensez qu’il y a quelqu’un à blâmer pour ce qui vient de se produire. Si Jérémie daignait écrire des tests on n’en serait pas là !

Lorsque cela arrive, il faut alors démêler le conflit d’idées de la bataille de personnes. C’est là qu’une carte de votre état de l’art est un atout précieux. Elle permet à votre équipe de se rappeler 3 faits :

  • nous n’avons pas de Meilleures Pratiques, nous cherchons seulement le meilleur pour notre contexte
  • nous n’avons pas tous le même background ni les mêmes préférences
  • d’autres que nous connaissent des problèmes semblables

Une fois le conflit identifié, il redevient, pour un temps, une tension, c’est à dire un problème intéressant, qu’il faut prendre le temps et le recul de résoudre, au lieu de chercher à trancher immédiatement.

Nous avons un conflit de priorités, que nous pouvons modéliser.

  • d’un côté il faudrait faire évoluer rapidement notre produit, afin de gagner des utilisateurs, en l’enrichissant de nouvelles fonctions
  • d’un autre côté, notre code n’est pas fiable
  • augmenter la complexité ET le nombre d’utilisateurs d’un produit peu fiable va nous exposer à un nombre croissant d’incidents
  • les incidents vont entraîner des urgences, réduires nos choix, casser la confiance

etc.

Nous pouvons illustrer ce conflit par une métaphore.

Paul sort de chez lui au pas de course car il a un rdv urgent. Mais il a pris ses mauvaises chaussures. L’une d’elle rend l’âme après 1 km : plus de semelle. Retourner à la maison ? Pas le temps ! Pour aller plus vite Paul décide d’aller pieds-nus. Mais il se cogne violemment l’orteil droit contre une bordure de trottoir. Il claudique. Il souffre. Paul doit aller aux urgences.

Un incident est le signe que vous devez améliorer votre état de l’art, et non pas le dégrader.

conflict-modelled

Publié sur Linked In le 18/09/2024