Posture de Scrum Master et intentions

Fleur Saillofest
4 min readMar 26, 2021

Je me pose souvent la question de comment accompagner mon équipe en tant que Scrum Master et quelle posture choisir. J’entends aussi mes collègues se questionner: “Est-ce que je sors de mon rôle si je pose telle question?”, “Est-ce que je dois rester en retrait ou intervenir dans l’opérationnel?”, “Est-ce que je dois les laisser plus autonome sur tel sujet ou leur donner mon avis?”

Une question m’aide beaucoup dans ces cas-là: quelle est mon intention?

C’est grâce à ma collègue Pauline que je l’utilise de plus en plus, parfois pour les autres mais d’abord pour moi. Qu’est-ce que je cherche à accomplir avec cette question, cette remarque, cette intervention? Est-ce que c’est mon égo qui parle? Est-ce que je cherche à défendre mes convictions?

Vous me direz “mon intention est bonne, je veux les aider!” Bien sûr que l’intention de départ, de surface, est bonne. Franchement vous en connaissez beaucoup, vous, des gens qui font des choses parce qu’ils pensent que ça va faire du mal? Et puis ça veut dire quoi bonne intention? Et bonne pour qui? Pour moi, pour l’équipe, pour l’entreprise?

J’ai envie que l’équipe que j’accompagne s’améliore, aille dans la bonne direction. Aïe. Ça grince encore. C’est quoi la “bonne direction” ? La direction de mon idéal agile? La direction de leur idéal ? La bonne direction pour le bonheur des individus de l’équipe? Pour le produit? Pour l’entreprise?

Je ne cherche pas ici l’intention générique mais plus précisément quelles sont mes attentes, qu’est-ce que je veux voir arriver quand je pose cette question ou fait cette remarque. Est-ce que je cherche à faire réfléchir les personnes en face? Est-ce que je veux que ça aille dans la direction de mes convictions? En fonction, je peux changer ma formulation. Ou choisir de me taire.

Je vous donne un exemple. Récemment j’observe le sprint planning d’une équipe de 6 personnes dont 4 nouveaux développeurs qui viennent d’arriver. Les anciens devs commencent à expliquer que pour connaître la capacité de l’équipe pour un sprint ils utilisent 1 point de complexité = 1⁄2 jour puis font une règle de 3 avec le nombre de jours de présence de chacun. Mon sang d’agiliste commence à frémir. Je me demande si j’interviens ou si j’attend un ou deux sprints pour voir ce que ça donne. Est-ce que je défends mes croyances ou est-ce que je leur apporte quelque chose? Au-delà de mes convictions de Scrum Master (ah les calculs d’apothicaires de vélocité), je suis mal à l’aise avec la méthode pour l’intégration des nouveaux. Finalement je leur dit “Je ne peux pas m’empêcher de dire quelque chose, est-ce que cette méthode vous permet d’être prédictif? Est-ce que vous regardez votre vélocité sur plusieurs sprints? Là vous intégrez de nouvelles personnes, comment savoir si ça va fonctionner pour eux?”. Je n’ai pas le temps de finir qu’il y a une levée de bouclier immédiate “Ca fait déjà 3 scrum masters qui nous disent qu’il ne faut pas faire comme ça. Ca marche pour nous et on délivre nos engagements de sprint alors pourquoi ne pas continuer?” C’est vrai ça pourquoi? S’ils délivrent de la valeur à chaque sprint, si ils sont prédictibles, pourquoi les embêter si ça marche pour eux de faire des règles de 3? Je les laisse tranquille.

A la fin du sprint, ils se rendent compte que ça n’a pas bien fonctionné. Ils proposent d’eux-mêmes de diminuer leur engagement au prochain sprint en gardant leur règle de trois sur la présence qui apparemment les rassure.

Si je m’étais arrêté un peu plus sur mon intention, j’aurais pu formuler ma remarque différemment. Par exemple, leur demander comment ils comptaient prendre en compte l’intégration des nouveaux dans leur calcul et leur engagement de sprint. Le début de mon intervention remettait en cause leur pratique de manière générale. Quel intérêt alors que je viens d’arriver et n’ai encore observé aucun problème de prédictibilité ? On se retrouve alors dans un combat conviction contre conviction qui ne nous fait pas avancer. Mon intention était plutôt de les sensibiliser sur l’intégration des nouveaux. De leur dire que c’était normal que ça perturbe leur engagement, que c’était ok de prendre moins de user stories. Ca n’aurait peut-être pas eu de résultats non plus, ils avaient besoin de s’en rendre compte par eux-même. Mais ça aurait placé le débat, la conversation sur le sujet qui m’intéressait: comment prendre en compte le fait qu’il y a 4 nouveaux sur 6 membres de l’équipe et se laisser un peu d’air le temps que l’équipe se forme. Ou j’aurais pu attendre le sprint d’après. Prendre un sprint pour les laisser expérimenter, se tromper, se prendre un mur. Les itérations sont faites pour ça. Peu importe. Cette fois-là n’a pas eu d’impact et c’est ok en fait, comme dirait ma collègue Pauline. Ces petits moments m’aident à apprendre et continuer à avancer dans ma pratique.

--

--