Le jour où j’ai découvert que j’étais un mauvais scrum master

read think learn

Il y a un mois, avant de partir en week end à la campagne, j’ai emprunté à notre bibliothèque d’équipe “Coaching agile” de Rachel Davies et Liz Sedley (traduit en français par Fabrice Aimetti). Le dimanche soir, en rentrant chez moi, je me suis dit que j’allais complètement changer ma façon de travailler. Voici les cinq comportements que j’ai décidé de ne plus jamais reproduire en tant que scrum master.

Faire du baby-sitting

J’avais enregistré, lors de mes premières lectures, que le Scrum Master devait “éliminer les obstacles : prendre en compte les problèmes qui surviennent à tout moment sur un projet pour les éliminer au plus vite, en évitant qu’ils ralentissent l’équipe.” (Définition de Claude Aubry.) Curieusement, mon cerveau avait analysé et enregistré cette définition de la façon suivante : “tu mettras en oeuvre tout ce qui rentre dans ton domaine de compétences pour éliminer tout élément ralentissant l’équipe.” Je me portais donc volontaire pour tout un tas d’actions du quotidien de l’équipe : imprimer le burndown, ajouter au scrumboard les tâches de l’équipe, contacter le product owner lorsque l’un des développeurs avait une question, informer le product owner d’une story livrée en recette…

C’est une erreur ! Rachel et Liz expliquent bien dès les premières pages du bouquin que l’objectif du scrum master/ coach agile est de “faire grandir et rendre productive une équipe […] Plutôt que de compter sur vous pour mettre en place les principes de l’agilité.”
J’ai réalisé que sur certains projets de plusieurs mois, j’étais devenue une vraie baby-sitter. L’équipe ne prenait aucune initiative, s’adressait à moi comme une sorte de référente du projet et était un peu perdue sans ma présence.

J’ai depuis tenté de changer radicalement mon comportement. Je dis “tenté” car cette posture d’accompagner plutôt que de faire n’est pas évidente et ne s’apprend pas en un jour. Je suis beaucoup plus dans une posture d’observation, d’écoute, d’accompagnement. J’essaye de m’effacer pour que à terme l’équipe n’ait plus besoin de moi. Par exemple, ce n’est plus jamais moi qui imprime le burndown. Je rappelle à l’équipe à quoi ça sert et je propose qu’elle s’organise seule pour imprimer le graphique qui peut les aider à savoir où elle en est dans son travail. La prochaine étape ? Parvenir à m’effacer le plus possible des réunions (comme celle de planification par exemple). Car en plus d’être baby sitter, j’ai encore tendance à être secrétaire. “ Comme dit Liz, “ne jouez pas à la secrétaire […] cela peut empêcher quelqu’un d’autre de s’impliquer dans la réunion”.

Mettre les gens dans des boîtes

Je démarre régulièrement des projets avec des équipes nouvelles ou des personnes avec qui je n’ai jamais travaillé. Il m’est arrivé d’avoir de vraies facilités à communiquer avec la plupart des personnes d’une équipe. Pour diverses raisons, nous nous entendions bien, nous n’avions pas de soucis à nous dire les choses. Et puis il m’est arrivé d’avoir beaucoup plus de difficultés avec certaines personnes. Au fur et à mesure des sprints, l’écart se creusait et nous ne parvenions pas à progresser ensemble. J’avoue avoir parfois baissé les bras très vite en tirant des conclusions trop hâtives : comme le manque d’expérience de la personne, ou la personnalité trop timide.

Je considère désormais que c’est une chance extraordinaire de repartir à zéro à chaque projet, de travailler sans cesse avec de nouvelles personnes. Liz dit : “soyez conscient du fait que les gens ont des préférences différentes en matière de communication. Vous devrez être très directifs avec certaines personnes et vous devrez laisser beaucoup de marges de liberté à d’autres.” C’est un exercice qui demande pas mal d’énergie mais j’essaye désormais d’être attentive à chaque personnalité et à être patiente quand certaines personnes n’acceptent pas si facilement le changement ou que l’harmonie d’équipe n’est pas immédiate.

Prendre des décisions à la place des autres

Pour faire avancer l’équipe, il m’est déjà arrivé de prendre des décisions à sa place. Comme par exemple, utiliser des pastilles de couleur pour indiquer l’avancement d’une story (jaune : la story a été discutée avec le PO, vert : la story est disponible en recette, rouge : la story est DONE). Je me suis ensuite étonnée que l’équipe avance dans ses tâches sans utiliser les 3 gommettes. Pourquoi ? Sûrement parce qu’ils n’y trouvaient pas d’intérêt ou trouvaient ça trop niais. Peut-être qu’ils auraient préféré une autre pratique. Rachel répète souvent “discutez-en avec l’équipe”. En effet, si l’idée et le format vient d’eux, ils seront probablement appliqués.

C’est peut-être mon passé de chef de projet web qui me conduit à prendre des décisions à tout-va. Désormais, quand je ressens le besoin de faire mon “chef”, je sors du plateau, je vais prendre l’air et je me calme. Je discute avec des personnes qui ne sont pas directement impliquées sur le projet. Et ça va mieux ! Je reviens avec des idées pour aider l’équipe à s’améliorer sans lui imposer un fonctionnement. Rachel explique qu’il faut essayer “de trouver d’autres coachs en interne ou en externe de la société pour lier connaissance et créer votre propre réseau de soutien”.

Vouloir à tout prix trouver une solution tout de suite

C’est assez satisfaisant de parvenir à identifier un blocage dans une équipe, et surtout une solution pour le contourner. Mais j’ai souvent eu le défaut de vouloir trouver une solution dès le moment ou le problème est identifié. Je me souviens d’un jour où l’équipe m’a expliqué qu’elle était bloquée sur le mode d’implémentation d’une user story complexe. Je leur ai proposé de consacrer une demi journée supplémentaire à la conception de la story. Puis je suis revenue vers l’équipe en expliquant qu’il me paraissait important de démarrer une des pistes étudiées et de ne pas passer trop de temps à la conception. Changer d’avis en un très court laps de temps c’est perturbant pour tout le monde et ça risque de gaspiller du temps et de fatiguer l’équipe.

Liz et Rachel disent : “ Si un problème a été mis à jour, vous voudrez effectuer quelques recherches avant de vous engager dans un plan d’actions”. Désormais, je n’ai aucun mal à expliquer à l’équipe que je n’ai pas de réponse immédiate. Je prends d’abord bien le temps de comprendre le problème et je me laisse parfois une ou deux heures pour venir avec une proposition.

Proposer trop de changements en même temps

Il y a cinq mois, j’ai démarré un projet avec une toute nouvelle équipe qui n’avait jamais travaillé ensemble, dont la moitié des membres n’avaient jamais pratiqué Scrum, jamais mis en place de tests fonctionnels automatisés, avec une maîtrise des tests unitaires très débutante. La semaine avant le premier sprint, je leur ai expliqué qu’il s’agissait de standards à appliquer au sein de notre cellule de développement, que l’on ne pouvait pas s’en passer et ce dès le début du projet.

J’ai proposé du changement et de l’aide méthodologique avant même que l’équipe m’en fasse la demande. J’ai exposé au même moment plusieurs actions d’amélioration avant même de regarder comment l’équipe travaillait. J’ai étouffé l’équipe de bonnes pratiques. Le résultat : je pense que l’équipe a vécu l’agilité non pas comme un état d’esprit mais comme un carcan de contraintes. De plus, elle s’est souvent sentie en “échec” car incapable de tenir tous les objectifs demandés. Liz et Rachel expliquent bien que l’équipe s’améliore par des “pas de bébé”. “Si vous identifiez un problème ou un objectif ambitieux, vous pouvez demander à l’équipe par quelles étapes elle passera. Plus petites seront ces étapes, plus il est probable que l’équipe les réalisera jusqu’au bout.

Ce bouquin m’a permis de démarrer une vraie conduite du changement personnelle. C’est curieux comme on peut s’enfoncer dans un rôle la tête baissée et avoir l’impression de bien faire. C’est amusant d’avoir l’impression de rendre service, alors que c’est totalement le contraire. Je le recommande pour trouver plein de solutions à des obstacles du quotidien de scrum master/caoch. En plus, il est écrit par deux femmes ! 😉

Et pour finir, je serais curieuse de connaître quel comportement VOUS avez récemment abandonné dans vos relations inter équipes… à vos commentaires !

Crédit photo

Ne ratez plus nos événements !

Pour ne rien rater de l'actualité GIW, inscrivez-vous à notre newsletter. Promis nous ne vous inonderons pas d'envois, seulement l'essentiel.

Nous ne spammons pas ! Consultez notre politique de confidentialité pour plus d’informations.

4 réponses

  1. Bon article qui montre en évidence que nous évoluons et/ou devons évoluer dans notre métier au fil de l’eau.
    je me suis rendu compte qu’il y a quelques années je faisait office de “maman” dans une équipe de support de niveau1 et que ce n’était pas bénéfique pour tout le monde. Je devais prendre des décisions, je devais les former sur tel et tel sujet … Au final je pense que ce n’était pas du tout la bonne méthode à avoir :-).

  2. Géraldine,
    Tu as dû voir que j’ai retweeté ton article en modifiant volontairement son titre : “Le jour où j’ai découvert que je pouvais être un(e) meilleur(e) scrum master.” En effet, j’apprécie particulièrement que ton témoignage soit basé sur le retour d’expérience et la prise de conscience, une très belle preuve de maturité, et je souhaite que tes nombreux lecteurs suivent leurs propres chemins avec ce même état d’esprit. Je rappelle que la traduction se trouve sur Amazon.fr ou sur Lulu.com.
    Amicalement, Fabrice

  3. @Aurélie : en effet, il faut faire confiance et laisser une chance à l’équipe de devenir autonome.
    @Fabrice : Merci Fabrice pour ton tweet et ton commentaire ! Et surtout pour la traduction de “Coaching agile”, sans quoi je n’aurais pu retirer autant de sens de cet ouvrage je pense. Pour le titre, je le voulais assez accrocheur. Mais effectivement l’idée est de se remettre en question pour progresser. Le message reste positif. J’espère que l’on se recroisera un de ces 4 à une coach clinic !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *