9 questions que les Scrum Masters et Product Owners devraient poser
Avant de devenir Scrum Master, je travaillais comme responsable technique avec différentes équipes. Une partie de ce travail consistait à prendre des décisions – et je pense que je m'en sortais plutôt bien. La capacité à décider rapidement et à m'affirmer font partie de mes traits de caractère.
Ces qualités ne m'ont cependant pas vraiment aidé quand je suis devenu Scrum Master. J'ai réalisé que pour réussir en tant que Scrum Master, je devais moins affirmer et poser davantage de questions. Comme cela ne correspondait pas à mon style naturel (et que ce n'étaient pas ces qualités qui m'avaient permis de réussir jusqu'à ce point de ma carrière), cela m'a été difficile au début.
Mais avec un peu de patience, je suis devenu de plus en plus doué pour poser des questions. J'aimerais partager avec vous quelques-unes de mes questions préférées. La plupart de ces questions s'appliquent aussi bien aux Scrum Masters qu'aux Product Owners.
2 questions sur les estimations
J'ai souvent besoin d'une estimation approximative de la part d'une équipe. Je ne vais pas les y tenir. (Je ne demande pas ici un engagement. Les estimations et les engagements ne sont pas la même chose.) Je veux vraiment juste une estimation approximative. Dans ce cas, voici une bonne question :
"Je n'ai pas besoin d'une estimation. Mais si je devais demander une estimation, quelle unité vous viendrait à l'esprit ? Des heures, des jours, des semaines, des mois ou des années ?"
Oui je sais, ces unités peuvent se chevaucher – quelques semaines peuvent représenter plus d'un mois. Mais une estimation comme « Oh, des semaines, quelques semaines. » est souvent suffisante pour pouvoir prendre une décision, ce qui peut aussi signifier décider de demander à l'équipe d'estimer le travail de manière un peu plus précise.
Dans les situations où j'ai une estimation officielle de la part d'une équipe, je pose souvent une autre question :
"À quel point êtes-vous sûrs de cette estimation ?"
Ici, on veut découvrir à quel point l'estimation est fiable et si les membres de l'équipe sont d'accord entre eux. Une estimation dont l'équipe est sûre à 90% sera plus précise qu'une estimation pour laquelle l'équipe n'est globalement pas très confiante et où les opinions divergent davantage.
Des désaccords au sein de l'équipe concernant l'estimation peuvent également être un indicateur que l'équipe a donné cette estimation de manière trop hâtive. Ce n'est pas forcément grave, mais il faut être conscient que l'estimation n'est alors pas aussi fiable.
3 Questions sur les décisions d'équipe
En tant que Scrum Master ou Product Owner, on souhaite parfois avoir une idée de la rigueur avec laquelle l'équipe a réfléchi à une décision. Voici trois questions que je pose souvent :
- "Quelles trois autres options avez-vous envisagées avant de prendre cette décision ?"
- "Quelle serait la pire chose qui pourrait arriver si nous continuons dans cette direction ?"
- "Qu'est-ce qui doit bien se passer pour que ce soit vraiment la meilleure décision ?"
Il ne faut peut-être pas poser les trois questions en même temps, ni les mêmes questions pour chaque décision de l'équipe.
De plus, en tant que Scrum Master ou Product Owner, vous ne posez pas ces questions parce que vous pouvez réviser la décision de l'équipe. Cependant, vous avez le droit de comprendre à quel point l'équipe se sent confiante dans sa décision et si elle était unanime.
Ces questions visent à révéler ce genre de désaccords. Quand on demande « Qu'est-ce qui doit bien se passer pour que ce soit vraiment la meilleure décision ? » et que quelqu'un répond « Tout ! », cela signifie généralement qu'il y a un problème.
2 questions sur les réunions
Je n'aime pas vraiment les réunions. Si je me trouvais dans un couloir avec un tas de serpents à un bout et une réunion à l'autre, je ne saurais pas dans quelle direction courir.
C'est pourquoi j'essaie autant que possible de réduire au minimum le nombre de réunions ainsi que le nombre de participants. Au début d'une réunion, je pose souvent les questions suivantes :
- "Avons-nous besoin de toutes les personnes présentes ici ?"
- "Qui d'autre devrait être là ?"
La première question vise à déterminer si on peut se passer de l'une ou l'autre personne. Je vois souvent des équipes agiles qui en font un peu trop en matière de travail d'équipe et de collaboration. Les membres de l'équipe ont alors l'impression qu'ils doivent participer à chaque réunion, même si elle est totalement sans rapport avec leur travail. Ça peut être par exemple le développeur JavaScript qui participe à une réunion pour décider s'il vaut la peine de passer à la nouvelle mise à jour du fournisseur de base de données.
Si les membres de ton équipe sont un peu trop enthousiastes concernant les réunions, remercie-les pour leur engagement envers la collaboration, mais fais-leur aussi comprendre qu'ils n'ont pas besoin d'être présents à chaque réunion. Établis la règle qu'aucun membre de l'équipe ne devrait participer à une réunion s'il ne peut pas y contribuer suffisamment ou en tirer suffisamment de valeur.
(Oui, cela peut être détourné. Tu devras peut-être expliquer à certaines personnes que cela ne signifie pas qu'elles n'ont plus à participer à aucune réunion. Au final, l'équipe dans son ensemble devrait avoir le droit de passer outre la décision d'une personne de ne pas venir à une réunion.)
La deuxième question vise donc à déterminer si quelqu'un qui n'est pas encore présent devrait l'être. Même si je déteste les réunions (je choisirais probablement les serpents), nous avons parfois besoin de plus de personnes dans les réunions.
En cas de doute, opte pour moins de réunions et moins de participants, mais certaines réunions doivent simplement avoir lieu – et ces réunions ont encore plus de valeur quand les bonnes personnes y participent.
1 Question pour se promener dans le bureau
Surtout lorsque je travaille en tant que Scrum Master, je passe beaucoup de temps à participer aux conversations dans le bureau. C'est aussi connu sous le nom de Management by Wandering Around (management par déambulation). Par exemple, lorsque je remarque qu'un développeur et un testeur ont une conversation apparemment importante, je vais parfois les rejoindre pour voir si je peux les aider avec quoi que ce soit.
(Bien sûr, il ne faut pas le faire à chaque fois, ni quand cela ressemble à une conversation privée !)
Parfois, les conversations que je surprends par hasard sont aussi précieuses pour d'autres personnes. Peut-être que le rédacteur technique devrait être au courant de ce que le testeur et le développeur ont décidé. C'est pourquoi je demande :
- "Est-ce que quelqu'un d'autre devrait être au courant ?"
Si c'est le cas, je propose de partager ces informations si cela m'est possible. Sinon, je propose d'aller chercher directement la personne concernée.
1 Question pour les Daily Standups
Lors du Daily Standup, je regarde le Burndown Chart de l'équipe et je me demande souvent comment l'équipe compte terminer tout le travail avant la fin du Sprint. Mais quand je demande ensuite à l'équipe si elle pense pouvoir tout accomplir, elle est généralement très optimiste.
Quand je trouve cela irréaliste, je regarde à nouveau le Burndown Chart et je demande :
- "Savez-vous quelque chose que j'ignore ?"
Peut-être que j'obtiens comme réponse qu'un des membres de l'équipe n'a pas encore mis à jour ses heures dans l'outil de l'équipe. Ou quelqu'un explique qu'ils ont certes un peu de retard en ce moment, mais qu'ils ont beaucoup appris et que tout s'accélère à nouveau. (Je trouve rarement cela réaliste, mais je l'entends souvent.)
Demander à l'équipe ce qu'elle sait et que j'ignore offre une excellente opportunité de synchroniser les hypothèses. Peut-être supposent-ils que tout va s'accélérer maintenant, alors que je ne le pense pas. C'est donc une excellente question pour révéler des hypothèses divergentes.
Conclusion : Les questions valent mieux que les affirmations
Lorsque j'ai endossé le rôle de Scrum Master pour la première fois, je ne connaissais pas encore le pouvoir des questions et j'ai raté de nombreuses occasions d'en apprendre davantage sur mon équipe et leur travail. Ce n'est qu'après un certain temps que j'ai découvert que je pouvais apprendre le plus en posant des questions et en écoutant vraiment les réponses.
J'espère que tu trouveras ces questions aussi utiles que moi.
Cet article provient du blog de Mike Cohn et a été traduit en français par nos soins.
