J’ai découvert avec plaisir la conf Agile Lyon organisée par le CARA le 4 juin dernier, et, entre les constats alarmants du professeur Gilles Leboeuf  (et ses apprentissages : saviez-vous que l’humain partage 60% de son ADN avec la banane ?) et le café Philo avec sa battle autour de la transmutation (est-ce changer de nature ? Vous avez deux heures), c’est l’intervention de Grégory Alexandre qui a retenu mon attention, parce qu’elle fait écho à plusieurs expériences de facilitation. 

Cette intervention portait le titre efficace « Mon équipe ne voit pas le problème », une situation que, j’imagine, tout scrum master a rencontré au moins une fois dans sa carrière : en tant que facilitateur, un peu extérieur à l’équipe, je peux repérer les problèmes à venir, et aider l’équipe à anticiper leur résolution. Mais la mécanique se grippe lorsque malgré mes interventions, l’équipe tarde à résoudre le défaut indiqué. Et plus je m’entête, plus les rapports se crispent. 

Dans un premier temps, je peux travailler sur moi-même, et plutôt que questionner les motivations de l’équipe, travailler sur les miennes. Mais dès lors que mon rapport à la situation est clair, je peux inviter l’équipe à réfléchir à nos interactions. 

Un problème, une situation problématique et une faille entrent dans une équipe 

C’est une affaire de perspective. 
L’un des aspects du rôle de scrum master, la levée d’obstacle (Impediment management, comme on dit), se traduit par la mise en visibilité des blocages à venir, et si c’est à l’équipe de les traiter, la mise à disposition de tous les éléments pertinents pour lui permettre de traiter au mieux.

Il arrive d’ailleurs que cet obstacle ne soit pas qu’une question de bug de prod : engagement en demi-teinte, management visuel peu entretenu, décisions de rétro abandonnées… 
En tant que scrum master, je pense avoir une meilleure vision des implications que laisser de tels défauts peut avoir, et des conséquences fâcheuses qu’un manque d’action entraînera, et j’ai une obligation de moyens pour faire progresser mon équipe. 

La situation qui m’occupait concernait un Product Owner qui, connaissant les ficelles du métier, chiffrait à la place de l’équipe, et les engagements de sprints étaient rarement tenus. J’avais beau discuter, argumenter, et m’obstiner, je n’arrivais pas à faire comprendre au PO qui s’offusquait de la fainéantise de son équipe (qui cravachait déjà pas mal) qu’il valait mieux laisser l’équipe chiffrer elle-même pour disposer de délais réalistes. 

A force de m’opposer et de prendre la défense des développeurs, je me suis retrouvé leur sauveur, et je me voyais victime du PO qui refusait de voir son erreur, alors que je devais tout autant être son persécuteur, suivant les modèles du triangle de Karpman. 

Plutôt que laisser ces jeux psychologiques s’installer, j’aurais pu prendre du recul, et m’interroger sur la situation. 

La faille que je voyais, c’étaient les décisions prises pour l’équipe, mais l’équipe, quoiqu’on décide à sa place, ne bougeait pas, et le PO qui jugeait de la facilité de réalisation des stories à la place de l’équipe.  

Ma situation problématique, c’était le fossé qui se creusait entre l’équipe qui cravachait comme elle pouvait, et le PO qui les taxait de paresse voire d’incompétence, sans prendre la mesure du travail fourni. 

Et le problème, c’est que je vivais personnellement l’injustice au point de prendre pour moi les critiques du PO. 

Un pas en arrière, un pas de côté

J’aurais pu rependre le lunemarchage de Grégory, mais il en parle mieux que moi.  

A la place, je vous parlerai d’un changement de perspective que j’aurais pu faire avec plus d’expérience. 
 
Tout d’abord, comme disaient les Toltèques : « Ne le prends pas pour toi. » 

Ou, formulé différemment, « ne pas se confondre avec son métier » : je ne suis pas scrum master de l’équipe, j’occupe le rôle de scrum master pour l’équipe, j’assure ses missions, mais les situations problématiques qui se présentent ne sont pas dirigées contre moi personnellement, mais inhérentes à la fonction. Déjà, ça donne un peu de mou à l’implication émotionnelle. 

Ensuite, je peux questionner mon lien avec la situation : pourquoi réagirai-je avec émotion dans une situation pareille ? Est-ce l’injustice qui me révolte ? D’ailleurs, je parle d’injustice, mais de quel côté se situe-t-elle : du côté de l’équipe à qui le PO impose des délais intenables, du côté du scrum master dont on ne tient pas compte de l’avis, ou du côté du Product Owner soumis à des pressions du client pour tenir d’autres délais encore moins tenables ? 

Deux perspectives différentes peuvent être également vraies : avec les éléments de mes interlocuteurs, je peux me projeter plus facilement dans leurs visions, et nous pouvons trouver un terrain d’entente.

 

Après m’être projeté dans la perspective de l’autre, je peux en profiter pour examiner la place du scrum master dans l’équipe, ou plutôt ma façon de la représenter :  

  • Est-il dans l’équipe, hors de l’équipe, à la frontière ? 
  • Où se situe-t-il par rapport aux autres membres, aux autres rôles ? 
  • Comment ai-je indiqué ces rôles, comment ai-je nommé les membres de mon équipe ? 
  • Quelles couleurs ai-je employées, quelles frontières, quelles relations et quels échanges ai-je représentés ? 
  • Qu’est-ce que j’ai oublié ?  

Cette nouvelle prise de recul me donne encore une autre perspective sur ma situation, et la place que j’y tiens : en questionnant et en représentant ma position dans le système, je peux prendre conscience des biais que j’y introduis, et que la souffrance et la crispation que j’éprouve viennent peut-être, en premier lieu, de ma façon d’envisager la situation. 

Changer collectivement de perspective 

Au final, si j’avais questionné mon Product Owner, si j’avais cherché « le problème derrière le problème », j’aurais pu avoir plus d’éléments pour me projeter dans sa situation.  

Dans la suite de mon parcours, à la faveur d’une formation de coaching, j’ai découvert l’animation déléguée d’Alain Cardon : la répartition, en co-responsabilité de missions habituellement échues au scrum master : le respect de la timebox, le rappel du sens des rituels et des réunions, la distribution de la parole, l’encouragement à l’action et la production d’une trace écrite des échanges survenus. Cela dit, une mission que j’ai régulièrement oublié de mener en étant seul scrum master, était celle du meta-feedbacker : en charge de prêter attention aux échanges, à la dynamique du groupe, il met en visibilité les interactions entre les membres du collectif pour que celui-ci se questionne et s’améliore. 

De telles observations permettent de mettre en lumière les dispositions dans lesquelles l’équipe est plus efficace (a-t-elle besoin de temps pour produire, ou la production se fait-elle par rebond, où chacun ajoute à la production de l’autre ?), les dispositions dans lesquelles les membres de l’équipe sont à l’aise (Gégé est un formidable secrétaire, et de prendre des notes ne l’empêche pas de participer activement aux discussions). 

Le retour que fait le meta-feedbacker à l’équipe, comme tout feedback, est factuel : il repose sur ses observations des comportements et des propos dans un contexte donné, sans aucun jugement. Il peut formuler des hypothèses et proposer des améliorations comme on le ferait d’une demande en CNV : en acceptant qu’elle ne soit pas satisfaite. 

La puissance du meta-feedbacker et son intérêt pour le groupe réside, à mon sens, dans l’opportunité qu’il donne au groupe d’étudier non pas son fonctionnement opérationnel, comme je l’ai beaucoup vu en Rétrospective, mais les tenants de sa communication et de sa collaboration.  

Ainsi chacun, en questionnant sa posture dans le système avec les membres de son groupe, peut aider son équipe à gagner collectivement en détente, en aisance, et en maturité.

 

Sources et références :