Dans mon activité d’accompagnement des acteurs du changement, j’observe souvent que les conflits sont mal exploités. Plutôt que d’être perçus comme des leviers d’amélioration, ils sont évités ou mal interprétés.
Prenons un exemple que je rencontre fréquemment : un(e) agiliste (coach agile, Scrum Master, etc.) confronté à un conflit entre deux membres de “l’équipe” accompagnée.
(Les guillemets autour du mot équipe indiquent que cette notion est en général à géométrie variable et demande une exploration spécifique).
Les réactions classiques face au conflit
Plusieurs types de réactions fréquentes de la part de l’agiliste exposé au conflit :
1️⃣ Évitement : Ignorer le conflit ou s’en plaindre. “Ça finira par s’arranger”, c’est pas grave, ça n’empêche pas d’avancer”, “J’en ai marre de devoir gérer les problèmes d’ego de ces deux-là !”
2️⃣ Explication psychologique : Attribuer le problème à une incompatibilité de personnalités ou de caractères. Ex. “ils ne s’entendent pas”, ”notre P.O. a un caractère difficile” .
3️⃣ Rationalisation isolée : Tenter de résoudre le conflit individuellement avec chaque protagoniste, souvent par des explications rationnelles, suivies d’injonctions à changer d’attitude. « Tu as tort de le prendre comme ça, sois raisonnable, pense aux accords toltèques… ».
Ces approches sont centrées sur les personnes impliquées dans le conflit.
Un conflit peut en cacher un autre : les conflits inter-métiers
Si l’on prend un tout petit peu de recul, très souvent le conflit évoqué implique deux métiers différents. J’ai tellement l’habitude de ces situations que je propose un pari à mes interlocuteurs dès l’évocation de la situation : laisse-moi deviner le métier de chacun ?
Ce petit jeu permet déjà de provoquer un certain recul sur l’explication psychologique (incompatibilité des personnes).
Sont donc fréquemment en conflit un représentant du métier de l’entreprise (ce que dans une démarche ‘agile” l’on appelle le PO ou Product Owner) et un développeur informatique, souvent ce que l’on nomme un Tech Lead, c-à-d un développeur expérimenté qui a une responsabilité technique plus importante par rapport à l’équipe. Mais ça peut être également avec ce que l’on nomme Scrum Master, un rôle introduit par le framework Scrum et souvent mis en place de manière assez floue.
Ainsi, les conflits se manifestent chez des personnes jouant des rôles spécifiques :
• Un Product Owner (PO) représentant le métier,
• Et un Tech Lead ou développeur ayant une responsabilité technique plus large.
A première vue, le conflit peut sembler interpersonnel, mais un regard élargi révèle qu’au travers des rôles, il découle de tensions structurelles ou organisationnelles.
Poser un regard systémique sur les conflits
Le regard systémique propose des patterns de décodage particulièrement efficaces dans ces situations.
1️⃣ Les tensions dues aux polarités organisationnelles
Une polarité est une tension naturelle entre deux besoins opposés mais complémentaires, comme :
• Vitesse 🆚 Qualité : Aller vite peut nuire à la qualité, et améliorer la qualité ralentit la productivité.
Ces polarités, mal équilibrées, génèrent des tensions dans le système et se traduisent in fine en conflits apparents entre personnes.
➡️ les arbitrages non gérés dans les roadmaps ou les tensions entre le Build et le Run génèrent fréquemment ce type de tensions.
2️⃣ Un déficit de communication dans la hiérarchie
Les conflits au niveau opérationnel peuvent refléter des déficits de communication à un niveau supérieur.
Remontons la chaîne hiérarchique de chaque protagoniste. Nous trouverons à un moment deux responsables qui ne se parlent pas, souvent pour éviter un conflit entre eux, et ainsi délèguent officieusement le conflit à leurs collaborateurs qui ne peuvent l’éviter au niveau opérationnel.
Cela peut nous amener jusqu’aux membres du CoDir, voire jusqu’au dirigeant lui-même qui demande deux choses contradictoires.
➡️ le conflit entre le PO et le Tech Lead permet de remonter jusqu’aux deux responsables de département qui ne peuvent pas se voir et donc n’arbitrent pas les priorités. En remontant jusqu’au CoDir, nous constatons que les Directeurs correspondants évitent soigneusement les sujets qui fâchent pour préserver une harmonie de façade dans le CoDir.
3️⃣ Les flous dans la communication
Selon Gregory Bateson, les conflits peuvent résulter d’ordres implicites dans les messages échangés ou de flous/contradictions dans les échanges.
En étudiant la manière dont les acteurs communiquent, il sera possible de décoder les ordres implicites, les flous dans la communication qui génèrent et entretiennent le conflit. Rappelons l’axiome “On ne peut pas ne pas communiquer” : ne pas communiquer fait toujours sens pour les acteurs du système.
➡️ Le P.O annonce “L’équipe de Dev doit augmenter sa vélocité”. Peut se traduire entre autres par :
1) je ne fais pas partie de cette équipe et ne suis pas solidaire des résultats
2) pour satisfaire mes enjeux personnels et parce que mon N+1 me met la pression, va falloir vous bouger !
4️⃣ L’acteur du changement comme catalyseur de conflit
Les approches agiles imposent souvent un langage, des rôles ou des pratiques qui entrent en tension avec la culture existante. Par exemple :
• Une “équipe” mal définie où les rôles sont flous et où en réalité chaque collaborateur poursuit ses enjeux personnels sans alignement sur une mission commune. Des pratiques individualisées comme les tickets d’incidents peuvent accentuer ces dysfonctionnements.
• Un P.O. sans prise en compte des relations politiques internes.
En amenant un langage vidé de sens partagé, des rôles sans ancrage dans la réalité de l’entreprise, la “transformation agile” brouille la communication et renforce les processus évoqués précédemment.
Bref, la « transformation » met le bazar et l’acteur du changement se retrouve bien embêté par les résultats obtenus (conflits, tensions,…)
L’intention oubliée de l’agilité
Historiquement, Scrum ou Kanban ne visaient pas seulement à produire « mieux, plus vite, moins cher ». Leur intention première était de mettre en lumière les blocages existants afin d’optimiser le système.
Cependant, sans mise en œuvre de processus explicites, de temp dédiés, de chaîne hiérachique pour exploiter les tensions générées, la “transformation” se limite à créer des conflits stériles, aggravant parfois les dysfonctionnements existants.
Voir les conflits comme des opportunités
Ce détour par « l’agilité » nous permet de revenir à la proposition de départ : voir les conflits comme des opportunités de changement organisationnel.
Les conflits ne sont pas des problèmes personnels à résoudre au plus vite, mais comme des signaux révélateurs :
• De problèmes de communication,
• De manque de clarté dans les responsabilités,
• De stratégie mal alignée,
• De déficit de prise en charge des tensions organisationnelles par le management.
Bref, des tas d’opportunités de changement…
Ainsi, en adoptant un regard systémique, les acteurs du changement peuvent transformer les tensions éprouvées en véritables opportunités d’amélioration de l’éco-système.
Avec Marc Brunet, nous entraînons les acteurs du changement à adopter ce regard pour retrouver de la sérénité, augmenter leur impact et aider les organisations à grandir.
Voir https://www.systemically.fr/parcours-regard-systeacutemique.html
Questions ouvertes pour les lecteurs :
- Comment gérez-vous les tensions dans vos équipes ?
- Quels outils ou pratiques utilisez-vous pour transformer les conflits en leviers de changement ?
Photo de Tima Miroshnichenko: https://www.pexels.com/fr-fr/photo/lumineux-leger-mains-main-6693358/