“Le Scrum Master ? Il s’occupe de l’équipe technique”
Vous avez déjà entendu cette phrase ? Moi oui, très souvent.
C’est une vision qu’on retrouve souvent dans les entreprises et qui peut être amplifiée quand l’entreprise est habituée à plutôt voir ce que j’appelle des “Scrum Master Chronomètres” (j’en parlais dans un précédent article que je vous mets en lien à la fin de celui-ci).
Et avec ce type de vision du rôle de Scrum Master, le Product Owner est généralement mis de côté.
Définition du rôle : pas d’ambiguïté
Et pourtant, la description du rôle du Scrum Master dans le Scrum Guide n’est pas ambigüe, la responsabilité du Scrum Master est divisée en trois :
- Envers l’équipe de développement
- Envers le Product Owner
- Envers l’organisation
Donc, pour moi, c’est simple : le temps du Scrum Master doit se diviser en trois :
- 33% dédié à l’équipe de développement
- 33% dédié au Product Owner
- 33% dédié à l’organisation
Et les 1% restant et bien… il souffle un peu, fait sa veille ?
Une répartition inégale, au besoin
Bon bien sûr, la réalité est tout autre et il va se passer de longs moments où l’équipe de développement ou l’organisation nécessitera bien plus de temps que les autres, mais je trouve assez pertinent qu’en tant que Scrum Master, vous vous demandiez régulièrement si vous avez passez assez de temps avec le Product Owner.
Le Product Owner est plus important ?
Je suis assez tenté de dire que surtout pour une équipe débutant avec Scrum, le besoin de Scrum Master pour l’équipe de développement est assez limité. En effet, il faut que l’équipe se fasse au rythme des cérémonies, mais c’est relativement facile (surtout si il y a un coach technique pour leur apprendre les bonnes pratiques comme le TDD et la conception émergente).
Par contre, le Product Owner va rythmer l’équipe de développement et ça peut être très bénéfique, comme une horreur ! (je vous mets un lien qui en parle en fin d’article)
Et c’est presque pire pour un ou une Product Owner débutant(e) qui arrive dans une équipe “mature”.
En effet, pour une personne qui devient Product Owner, parfois pas spécialement par choix et sans trop d’information, le changement peut être brutal et inquiétant.
Inquiétant car la personne se retrouve dans le brouillard, et comme j’aime bien dire : ce n’est pas le changement qui fait peur, mais l’inconnu.
L’être humain lui, est un habitué du changement. Nous sommes hyper adaptables, par contre, nous bloquons facilement en face de ce qu’on ne comprends pas.
Donc, en tant que Scrum Master, vous ne devez pas négliger cette relation que vous devez construire avec votre PO. Ecrire des User Stories qui ont du sens, préparer des objectifs de sprints, communiquer avec les parties prenantes en mode empirique plutôt qu’en mode itératif… Tout cela n’est pas habituel pour un ancien chef de projet par exemple ou un métier habitué à fournir des pages de spécifications.
Vous faites quoi demain ?
En conclusion, si vous êtes Scrum Master, demandez-vous si vous passez assez de temps avec votre Product Owner et si vous êtes PO et que vous vous sentez un peu seul(e), que diriez-vous de solliciter votre Scrum Master dès demain pour parler de votre relation avec l’équipe de développement, avec vos utilisateurs ou pour vous aider à travailler vos compétences d’écriture de User Story comme j’en parlais dans cet article : Une astuce pour mieux écrire ses User Stories ?
Voici aussi l’article dans lequel je décris ce qu’est un Scrum Master Chronomètre, et un autre parlant du PO qui permet de rythmer le reste de l’équipe.
Photo by Daniel Cheung on Unsplash