Dans une équipe autogérée agile, les conflits inévitables qui peuvent surgir entre les membres de l’équipe sont complexes à arbitrer. Contrairement aux projets pilotés traditionnellement de manière hiérarchique, où la conciliation et la décision reviennent au chef de projet ou au manager du service, l’organisation agile repose sur la faculté de l’équipe à s’autogérer. Plus facile à dire qu’à faire… sauf si le Scrum Master ou le coach agile mettent en pratique la Communication Non Violente Agile (CNV-A). Dans ce nouvel article sur la CNV-A, Didier Joliot décrit, dans un cas pratique, comment définir la première étape de la résolution de conflit entre un Product Owner et 2 développeurs.
Dans les démarches agiles de type SCRUM ou SAFe, un certain nombre d’étapes permettent de passer de la définition de la vision produit à la validation de la valeur que celui-ci apporte aux utilisateurs et au Client final.
Didier Joliot est, entre autres compétences, un expert et coach agile expérimenté. Il a créé également la méthode CNV-A, qui hybride la communication non violente et la démarche agile pour aider à la résolution de conflits au sein des équipes agiles.
Lire aussi : Le coach agile et sa posture de médiateur
Lire aussi : Comprendre la Communication Non Violente (La CNV au service du coaching agile)
Avant d’illustrer, dans un cas pratique, comment la CNV-A peut aider à co-créer la vision de la résolution d’un conflit au sein de l’équipe agile, il est indispensable d’avoir en tête les étapes d’une démarche agile.
Comme vous le constatez dans le tableau ci-dessous, à chacune des étapes agiles correspond une étape CNV-A, à l’objectif similaire, mais cette fois-ci tournée vers la résolution du conflit et non pas vers la réalisation du produit.
Etape
Agilité
CNV-A
1
Icebreaker et Vision du produit
Icebreaker et Vision sur la résolution du conflit
2
Analyse de l’existant : partie “Exploration” du design thinking
Observations : Historique du conflit et faits validés
3
Analyse de l’existant : partie “Analyse” du design thinking (ex: Empathy map)
Sentiments : identification des charges émotionnelles associés aux observations
4
Analyse des besoins : partie “génération des idées”
Besoins : générer des idées
5
Analyse des besoins : partie “prototypage et test”
Demande : passer du besoin à la solution (étude de faisabilité …)
6
Formalisation de la solution : énoncer les items de solution (User Stories) de façon claire et non ambiguë
Demande : formaliser les énoncés de solution
7
Analyse de la valeur des items
Demande : juger de la priorité des observations pour planifier les demandes
8
Pilotage des incréments (PI en SAFe/sprint planning en SCRUM)
Demande : piloter les incréments de solution du conflit (liste des observations à prendre en compte en priorité)
9
Contrôle de l’ensemble
Validation
10
Validation de la réunion par des sketchnotes
Validation par des sketchnotes de bilans
11
Validation par un “ROTI”
Validation du dossier par les parties à l’aide d’un « ROTI »
Le cas pratique de coaching agile utilisant la CNV-A, qui va vous être détaillé ci-dessous, illustre la première étape qui consiste à co-créer la vision de la résolution d’un conflit au sein de l’équipe agile.
Illustration de la CNV-A pour définir la vision commune
La situation
Julien est Product Owner chargé de mettre en place une application RH. Or, un conflit survient, lié à ses postures et sa communication par rapport aux autres membres IT de l’équipe SCRUM.
Didier est coach agile et est mandaté pour être médiateur et voir les possibilités de résoudre le conflit.
La vision sur la résolution du conflit : introduction avec l’icebreaker
Reprenons le contenu de cette étape préliminaire.
Dans un premier temps il s’agit de “briser la glace” afin que les participants se détendent et se mettent dans un bon état d’esprit. On leur propose, avant d’entrer dans le vif du sujet, un jeu simple, ludique, sans les mettre en difficulté : un “icebreaker”.
Par exemple : Afin que chacun se dévoile un peu, mais pas trop … Chacun va tirer 3 questions de son choix dans le “questionnaire de Proust”. Les réponses seront l’occasion d’échanges décontractés et un “sketchnoteur” peut proposer une illustration “sympa” résumant chaque partie.
Le sketchnoteur, quant à lui, fournit deux planches qui permettent, de manière claire et conviviale, de présenter les personnes à tous les protagonistes.
Il s’agit, ensuite, de présenter la médiation aux différents participants : Julien d’un côté (PO), le SCRUM Master (Jean) et 2 développeurs de l’autre (Fatima et Mohamed).
- Didier rappelle la demande faite par l’équipe IT de trouver un consensus pour redresser la situation et résoudre le conflit qui dure depuis un an.
- Didier présente son rôle de médiateur. Il décrit notamment ses piliers.
- Didier présente aussi les quatre étapes de la CNV-A et demande les avis de chacun sur la démarche, par exemple le rythme qu’il faut lui accorder.
Un moyen de démarrer le tour de table est de leur faire faire un parcours de vie critique …
Identifier les valeurs et la force de caractère de chacun
Chacun est invité à positionner ses valeurs et à réfléchir sur ses forces de caractère grâce à une représentation visuelle.
Pour les valeurs, on s’appuiera sur un modèle simple, le but étant que chacun propose une vision de soi qui puisse se comparer avec celle des autres. D’autre part :
- Il vaut mieux que chacun note ses valeurs fondamentales et pas celles non signifiantes
- Il faut les mettre de telle façon que plus vous êtes au bord extérieur, plus vous êtes fixé et intransigeant sur cette valeur.
Concernant les forces de chacun, on peut utiliser le quadrant ci-dessous (ou une autre technique, comme l’Ikigai) :
Si le conflit était grave, avec des conséquences importantes pour l’entreprise, et si les participants (en nombre limité) voulaient aller plus loin, on pourrait utiliser la démarche un peu plus complète, par exemple celle de “ennéagramme” qui positionne chacun en termes de profils.
Ceci dit, le dessin a davantage pour but d’appréhender plus finement chaque participant, mais n’a pas pour but d’être une étude scientifique (aucun test de personnalité n’est parfait ni exhaustif), ni la vocation à être communiqué : le support ne fera pas partie du résultat d’étude, ce sera juste un facilitateur pour le médiateur.
Il faut bien comprendre que cette étape essaye cerner “au mieux” les personnalités de chacun, de manière à en tenir compte pour identifier les problèmes entre les profils, voire dégager des biais cognitifs.
Objectifs généraux et pitch liés au conflit
Il s’agit d’abord de définir le conflit afin de mieux le contextualiser.
Chacun doit donc décrire sous la forme d’un “pitch” la nature du conflit, ou compléter le pitch à tour de rôle, afin d’aboutir à un consensus sur ce qu’il est et ce qu’il n’est pas.
Par exemple, après discussions, voici le texte obtenu :
Problème :
Le conflit existe entre Julien, PO du produit “Perso”, et l’équipe IT (2 développeurs et un Scrum master). Il concerne le rôle de PO attendu de l’équipe, mais aussi le manque d’autonomie de l’équipe IT.
Il ne concerne pas le conflit sur le dernier sprint et ses mauvaises estimations.
La solution attendue :
Pouvoir améliorer la participation du PO au projet, tout en ne le submergeant pas, mais aussi mettre en place des dispositifs pour donner les moyens de ne pas toujours attendre du PO la moindre décision.
Elle ne concerne pas le conflit sur le manque de ressources de l’équipe (traité par ailleurs).
Validation:
L’équipe étant auto-organisée, les décisions lui appartiennent. Toutefois, celles-ci seront soumises à l’approbation des managers (en CODIR) si un engagement financier (pour un dispositif de solution) venait à dépasser 30K€.
Le plan d’action doit être à court terme (moins de 2 mois pour être effectif et apporter un bilan jugé positif par les participants) et à moyen terme (dans les 6 mois à venir, pour consolider le résultat des premières actions et les ajuster).
Le plan d’action sera suivi et revu, de manière agile, au cours des rétrospectives du projet, et par la Direction tous les 2 mois (4 CODIR, 3 itérations à prévoir).
Données :
On estime que le conflit actuel coûte :
- d’une part en termes d’impact sur la vélocité IT : on estime qu’au moins 30% du temps est perdu par manque de communication fluide et claire entre les parties,
- et, d’autre part, en termes de risques (turn-over : déjà 3 démissions IT en l’espace d’un an; le SCRUM Master voici 2 mois, 2 développeurs dans les 6 derniers mois).
L’enjeu principal est de rendre l’équipe pérenne (aucune démission dûe aux causes de ce conflit pour les 6 mois à venir) et d’observer a minima une vélocité (nb de pts réalisés dans un sprint/dev) en progression.
La démarche CNV-A décrite par Didier Joliot combine donc la Communication Non Violente aux approches agiles. C’est un outil extrêmement efficace à la résolution de conflits au sein d’équipes agiles.
Si cette démonstration illustrée vous a intéressé(e) et que vous souhaitez en savoir plus sur sa mise en oeuvre complète (je vous rappelle qu’il y a 11 étapes, et que cet article illustrait la première, sur la vision du conflit), n’hésitez pas à contacter Didier Joliot, créateur de la CNV-A et auteur du fond de cet article.
L'auteur
Didier JOLIOT
Didier JOLIOT est formateur de l’offre Modern Product Agility (MPA) mise en place avec Stéphane BADREAU et couvrant tant l’aspect de savoir-faire agile que celui du savoir-être.
Didier a une grande expérience professionnelle (plus de 40 ans) et très diversifiée.
Il a d’abord été développeur puis responsable qualité et certification de logiciels temps réels critiques (Airbus, systèmes d’armes, nucléaire …). Il a été ensuite consultant pour les MOE bancaires, AMOA, directeur de projet, et enfin expert auprès des managers pour la stratégie des SI (« Portfolio Management » et architecture d’entreprise).
Il a pratiqué le cycle en V, et, depuis 2012, l’agilité. En devenant alors coach agile il a aidé de nombreuses équipes Scrum et de nombreux programmes « à l’échelle » sur des bases SAFe.
Il a écrit 5 ouvrages et de nombreux articles. Il a créé, de plus, plusieurs méthodes dans des domaines variés : la CNV-A, mais aussi le langage « Business Modeling Language (BML) », les tests ATDD avec « l’algorithme des tamis successifs », etc.
Pour plus d’informations :
Contacter Didier Joliot : Profil Linkedin
Le blog MPA : Le blog MPA
Formation entreprise : Découvrez le programme "Agile Business Analyst"
Vous souhaitez, vous aussi, publier un article sur notre site?
Contactez-nous en remplissant le formulaire de contact.