Résoudre une situation conflictuelle au sein d'une équipe

Résoudre une situation conflictuelle au sein d'une équipe

> Se rapportant à Scrum* , Ken SCHWABER - l'un deux des inventeurs qui mets en place en tant que consultant cette méthodologie dans les sociétés qui souhaitent y avoir recours - évoque dans son article « Nothing is for free » du 12 Septembre 2004, le problème de résolution de situations conflituelles au sein d'une équipe de développement. Son approche pragamtique du problème est suffisamment intéressante et de portée générale pour que cela mérite de votre part un peu d'intérêt.

Rien n'est gratuit !

« Rassemblez une équipe et des phénomènes merveilleux surviennent telles que collaboration et productivité. Le « ScrumMaster » doit-il se préoccuper d'autre chose ?
Le développement « Agile » conduit à des gains de productivité. Les équipes de développeurs, gérant leur propre travail dans des espaces communs surpassent les développeurs encadrés de l'extérieur assis dans des box individuels ou des bureaux. Ces équipes sont au moins deux fois plus productives. Cette productivité est couplée à d'autres bénéfices tels qu'une plus grande créativité lors de la résolution de problèmes, une plus grande qualité grâce au contrôle réciproque du travail , et un meilleur moral grâce au phénomène de sociabilisation. Tous ces bénéfices semblaient être parfaitement gratuits !

> Rassemblez une équipe, obtenez son engagement sur un objectif et mettez les au travail dans une enceinte commune de travail. Qu'a-t-on perdu en sortant les membres de l'équipe de leur bureau individuel ? Qu'a-t-on perdu en leur demandant de se gérer en tant qu'équipe ?
Des conflits ! Cela n'est pas surprenant ; il arrive que les membre d'une même équipe qui travaillent sur le même lieu, avec un ensemble d'engagements et de dates d'échéance, aient souvent des points de vue différents sur la meilleure façon d'accomplir leur tâche. Ils viennent parfois travailler avec une humeur très peu encline à la collaboration, ressemblant plus à Attila le Hun qu'à « Tom », l'homme adulte qui s'accomplit dans son métier de programmeur.

> Les conflits sont inévitables. Néanmoins, rien dans le vocabulaire « Agile » ne dit ce qu'il faut faire lorsque celà survient. À ce jour, nous avons tous souhaité tirer les bénéfices de la méthode sans en évaluer les coûts. Pas de prodige, pour qui aime jouer avec les conflits ?

Je me trouvais récemment chez un client lorsqu'éclata une dispute. Une analyste était remontée parce qu'un programmeur avait pris de la liberté avec un « Design » déjà validé sans la consulter. Le programmeur pensait que le changement était si minime qu'il restait dans ses prérogatives. L'analyste pour sa part avait le sentiment qu'il ne respectait pas son travail et les responsabilités qui lui incombaient. Le ton monta, les nerfs s'avivèrent et les larmes coulèrent. Les autres membres de l'équipe tentèrent, sans résultat, une médiation pour apaiser le conflit. Celui-ci ne cessa que lorsque chacun des belligérants eut quitté la pièce commune pour se retrancher dans un espace privé où il put panser ses blessures et calmer ses nerfs. Tous deux étaient déchirés entre le sentiment d'avoir raison et la gêne de s'être affrontés devant le reste de l'équipe. Ni l'un ni l'autre ne savait que faire.
Je ne suis pas spécialement entraîné pour la résolution de conflits. Losque je pénétrai dans la salle de travail de l'équipe, chacun avait le nez sur son poste de travail. Ils étaient très affectés par ce qui venait d'arriver. Je sentis qu'il fallait qu'on en parle tout de suite et nous nous réunîmes pour partager les sentiments de l'équipe. Tous étaient embarrassés d'avoir été témoins de la dispute. Ils se sentaient fautifs de ne pas avoir su aider les protagonistes à résoudre ou éviter leur conflit. Ils étaient également agités et s'inquiétaient que cela puisse affecter leur famille, leur équipe, et ils ne savaient pas quoi faire pour solutionner le problème. Nous décidâmes qu'il n'était pas possible d'ignorer la dispute, car laisser des ressentiments non résolus était propice à détériorer l'atmosphère qui jusqu'alors avait été saine et collégiale. Pire encore, nous dûmes reconnaître que l'équipe ne serait plus à même de travailler ensemble si d'autres conflits non résolus survenaient.

Nous élaborames les règles suivantes.

  1. Accepter que la survenue d'un conflit soit un événement naturel lorsque des gens travaillent ensemble.
  2. Si un conflit survient, le travail doit s'arrêter et ne doit reprendre que lorsque le conflit est résolu.
  3. Dans un premier temps, chaque membre de l'équipe doit exprimer son (re)sentiment sur la situation (à ne pas confondre avec l'analyse de la situation).
  4. Tout le monde doit travailler à l'élaboration de la solution.

Nous fîmes l'hypothèse que si aucune solution n'émergeait c'était probablement parce que sous le coup de l'émotion nos pensées s'obscurcissaient . Nous répétâmes donc les étapes 3 et 4 jusqu'à ce que ce qu'une solution soit trouvée et que chacun soit capable d'affimer qu'il se sentait bien.

Comme je ne suis pas du tout spécialiste de la gestion de ce genre de situation, et j'ai donc recommandé à l'encadrement de cette entreprise d'en fournir un afin qu'il enseigne aux équipes comment résoudre les situations conflictuelles d'une façon plus efficace. Ce spécialiste serait certainement plus compétant, sachant gérer un plus grand nombre de types de situations conflictuelles que leurs équipes et moi ayons déjà eu à gérer.

Lorsque j'implémente un processus Agile, j'aide parfois l'entreprise à établir des règles de conduites, ou d'étiquette. Je le fais parfois parce qu'il exsite déjà un certain degré de malveillance existe déjà et je ne veux pas l'exacerber. D'autre fois, j'aide à établir les règles parce que j'ai le sentiment que les gens n'arrivent pas à sympathiser ; parfois cela survient en raison d'arrière-plans culturels différents, parfois cela est dû au fait qu'ils ont passé tant de temps à travailler seuls qu'ils ont oubliés, s'ils l'ont jamais su, comment travailler en équipe. Voici certaine des règles que nous avons imaginées :

  1. Ne jamais utiliser le genre de locution : « le travail que tu... » parce que l'autre personne peut se sentir mise sur la sellette et agressée.
  2. Ne jamais se référer au passé (« il y a trois mois tu as dit….! »).
  3. Être à l'heure aux réunions ; si vous êtes en retard, excusez vous et payez une « pénalité » de retard.
  4. Afin d'éviter que tout le monde parle en même temps, utilisez un crayon pour désigner la personne qui a la parole. Qui tient le crayon en l'air à la parole et tous les autres l'écoutent.
  5. L'opinion de chacun est importante, elle doit être comprise et prise en compte.
  6. On ne s'interpelle pas.
  7. Etc. selon la culture d'entreprise, d'équipe, la situation et l'expérience.

> Rétrospectivement, je suis surpris de ne pas avoir prévu ce coût. Les membres d'équipe s'étaient trouvés jusqu'alors dans des situations relativement dénuées de conflits, avec leurs dirigeants portant l'entière responsabilité de résoudre toute ce qui pouvait entraver la marche du projet. Maintenant cela revient à l'équipe elle-même. »

* Scrum : méthodologie de développement appartenant à la famille des méthodes dites « Agiles » ; cf. l'article « Scrum - ce qu'il faut en savoir. »

Article et traduction par Lionel RAFFIN pour www.smart-doc.org
Édition 30 Mars 2006





Cet article provient de Smart-doc.org
http://smart-doc.org/