Auteur : Fabio Panzavolta

Contexte

Dans votre mission de Scrum Master, un manager vous a demandé d’accompagner la mise en place d’un cadre Agile dans une équipe qui, selon lui, en a bien besoin !

Vous vous retrouvez ainsi à accompagner une équipe qui démontre peu d’engagement à adhérer au cadre de travail, peu d’envie à se challenger, à être dans un processus d’amélioration continue, à s’entraider pour arriver à un objectif partagé.

La qualité du produit n’est pas fantastique et cela ne semble gêner que vous.

Lorsque vous essayez de dynamiser l’équipe, ou de susciter de la réflexion en posant des questions ouvertes, vous éprouvez à chaque fois un lourd sentiment de solitude face au manque de réaction.

Les membres de l’équipe de développement restent tard le soir, particulièrement les veilles de mise en production. Ils font leurs heures de présence et travaillent consciencieusement, que peut-on leur reprocher ?

Enfin, lorsque l’équipe de développement rencontre des difficultés techniques, elle est déçue par votre manque d’expertise technique. Et oui, cela fait bien des années que vous n’êtes plus à la page, maintenant que vous êtes devenu expert dans l’art de l’utilisation du post-it.

Symptômes

Que ce soit pour une mission en interne dans votre entreprise ou chez un client, votre mandat d’intervention baigne dans un océan d’ambiguïtés.

Beaucoup trop de sous-entendus et d’éléments implicites viennent créer toutes les tensions que vous observez et qui vous font vivre des journées pénibles.

Finalement, vous ne savez pas vraiment qui veut réellement de votre accompagnement et à qui vous avez facilement accès pour mener à bien votre mission.

Probablement le mandant qui est souvent un manager. Mais qu’en est-il du client (équipe) lui-même ?

Accompagnez-vous l’équipe de développement, l’équipe Scrum, le Product Owner, l’équipe Scrum ainsi que ses managers ?

Comment doit se dérouler votre accompagnement ?

Au-delà de votre titre de Scrum Master, vous ne savez pas non plus avec quelles postures vous êtes attendu par votre client : formateur sur l’Agilité / coaching individuel / coaching d’équipe / facilitateur / expert Java / expert en automatisation des tests / expert DevOps / reporting-master / Jira-master / magicien…

Etes-vous seulement en mesure de dire ce dont vous êtes (ou n’êtes pas) responsable ?

Et savez-vous qui est responsable, et de quoi ?

Avez-vous clarifié avec le mandant et le client si vous apportez ou non dans vos bagages une expertise technique en complément de votre expertise sur l’Agilité ?

Causes

Dès le début de votre intervention, vous avez investi les lieux plein de bonne volonté, d’envie de bien faire les choses. Dans ce démarrage, parfois dans l’urgence d’une crise ou dans la sérénité d’un départ posé et sans piège visible, personne n’a vraiment pris le temps de clarifier votre mandat.

Vous souhaitez vraiment aider le client, vous êtes d’ailleurs payé pour cela !

Mais bien souvent, le client n’a pas exprimé une demande d’aide, ou alors pas le genre d’aide que vous avez en tête.

Si le client est également le mandant, la demande d’accompagnement est explicite et il est assez probable que la motivation du client soit réelle.

Mais si le client n’est pas le mandant, il est fort probable qu’il ne partage pas les enjeux du mandant. Le client n’a alors aucune envie de changer et observe avec indifférence voire méfiance le pion que le mandant lui a assigné.

Remèdes possibles

Un remède simple consiste à déminer le terrain avant même d’accepter et commencer la mission.

Si vous vous sentez obligé d’accepter une mission avec des conditions que vous ne pouvez pas discuter, ne vous étonnez pas ensuite d’avoir de piètres résultats.

Pour cadrer la mission, vous pouvez clarifier la relation avec un contrat élaboré à l’occasion d’une rencontre tripartite, précisant qui est le mandataire et ce qu’il reçoit comme mandat d’intervention, le mandant, le client / système qui va recevoir l’accompagnement.

Libre à vous de challenger dès le début le mandant et sa vision de l’intervention.

Par exemple, pour un Scrum Master, êtes-vous là pour faire grandir l’équipe de développement ou bien êtes-vous là pour aider l’organisation à comprendre et mettre en oeuvre plus d’agilité au-delà de l’équipe Scrum ?

Pour un Product Owner, êtes-vous là pour recevoir les ordres plus ou moins capricieux des utilisateurs ou des managers et les transmettre sous forme de User-Stories à l’équipe de développement, ou bien disposez-vous vraiment des leviers pour maximiser la valeur du produit.

Le cadrage par un contrat est un bon moyen pour se mettre d’accord sur les attentes des différentes parties.

Par exemple jusqu’à quand va durer l’accompagnement – Est-ce pour aider ponctuellement une équipe sur 3 mois ou bien pour accompagner toute la transformation d’un département sur plusieurs trimestres ?

Dans le but d’atteindre quels résultats – Comment le client et le mandant comptent-ils mesurer l’atteinte de leurs propres résultats ?

Avec quelles responsabilités – A qui devez vous rendre des comptes et sur quoi, en prenant garde à ne pas endosser les objectifs du client lui-même ? A qui aurez vous accès pour mener à bien votre mission ?

Avec quels moyens – les différents clients s’engagent-ils à préserver du temps pour que vous puissiez travailler avec eux ? De quelle durée et à quelle fréquence ?

Avec quels outils – vos outils de formateur ; de coach ; d’expert technique ; de facilitateur ; de diplomate ; de médiateur ; de négociateur… ?

Conclusion

A l’instar d’un contrat de cadrage établi par un coach professionnel, un cadrage d’accompagnement pour un Scrum Master (ou un Product Owner) est un socle puissant pour bâtir un partenariat sain entre les différents individus, et aussi pour clarifier les frontières de la mission.

Plus le contrat et les frontières de l’intervention sont clairs, plus saine sera la relation, meilleures seront les chances de réussite.
Dans le respect du Manifeste Agile, le contrat n’a pas pour but de créer une séparation entre les acteurs, mais d’accroître la transparence du système pour une meilleure collaboration.