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

About the author

Géraldine Legris

Je suis coach de sens.
Je crois que l'on fait bien les choses quand elles ont du sens : qu'elles répondent à un objectif aligné avec qui l'on est. Que l'on est meilleur à plusieurs. On naît bienveillants. Il y a plein de façons d’apprendre et surtout pas celle que nous avons suivi enfants. Le couple ne fonctionne que lorsque chacun a connaissance de qui il est, entretien sa liberté et se remet en question. Le feedback est essentiel. Et il y a une façon de le faire. Ca s’appelle la communication non violente. Les managers, on a besoin de vous. Et vous n’êtes pas seuls ! Et vous adorerez ce que vous faites quand vous oserez vous remettre en question. Nous ne savons plus jouer pour la plupart. Le jeu est le meilleur outil de dialogue avec nos enfants et entre équipes. La famille c’est un socle. C’est ce qui explique qui nous sommes. Mais ce n’est pas simple. Ce qui motive : un cadre clair, des règles, du feedback. Rien ne marche sans invitation.

View all posts

5 Comments

  • Je me replonge dans ton article que j’avais déjà lu l’année dernière, et je me rends compte que j’ai progressé sur certains aspects que tu mentionnes et qu’il me reste des marges de progrès sur d’autres.

    Le baby-sitting (les anglosaxons parlent de Scrum Mom) c’est effectivement quelque chose sur quoi je travaille…

    C’est parfois difficile pour un ScrumMaster de ne pas prendre des actions « concrètes » / « productives » pour justifier sa présence dans l’équipe…
    Et c’est d’autant plus vrai si le ScrumMaster est dédié sur un seul projet (ce qu’il faut éviter sur la durée je pense, sauf si le ScrumMaster est également développeur)

    « Vouloir à tout prix trouver une solution tout de suite » et « Décider pour les autres »… Pas facile non plus de lutter contre ces penchants…
    En tant que ScrumMaster on a souvent envie de montrer qu’on est utiles, et trouver une solution (surtout quand elle marche) est un moyen de se sentir utile. Mais c’est sûr que c’est mieux d’apprendre à l’équipe à s’en sortir seule, même si ça doit prendre plus de temps.

    Tout ça fait écho à des échanges que j’ai pu avoir avec Pablo sur son point de vue « ScrumMaster = Coach Agile » (qu’il a développé dans un article récent). Tout ce que tu décris dans ton article, c’est une posture de coach.
    Tu es donc déjà « Coach Agile », surtout que depuis fin 2014 tu es sûrement au top ! 😉

    • Merci Nicolas pour ton feedback !
      Avec plaisir pour discuter un de ces 4 avec toi de l’attitude du scrum master versus celle du coach agile.

  • Bravo pour cette prise de conscience. Après quelques expériences j’en suis arrivé à réaliser qu’un Scrum master a besoin d’un regard externe pour éviter les travers dont tu as réussi à t’extraire.

    • Du coup pour répondre à la question en fin de billet : j’ai énormément progressé dans mon rôle de facilitateur d’entreprise depuis que nous travaillons en binôme. Nous nous régulons et nous coachons mutuellement en permanence.

Laisser un commentaire

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