3 erreurs des Scrum Masters et comment les corriger

Être Scrum Master peut être une tâche vraiment difficile.

Si tu donnes trop de conseils et d'assistance à une équipe, elle s'habitue vite à se laisser guider par le Scrum Master pour tout. Mais si tu lui donnes trop peu d'assistance, elle se développe plus lentement qu'elle ne le pourrait. Résous quelques problèmes pour l'équipe et bientôt on attendra de toi que tu résolves chaque problème. Mais si tu ne résous pas les problèmes de l'équipe, les membres finiront même par arrêter de signaler leurs obstacles et problèmes à leur Scrum Master.

Les Scrum Masters marchent sur une ligne étroite et il est facile de faire des erreurs. Dans cet article, nous décrivons trois erreurs que les Scrum Masters commettent fréquemment, et pour chacune d'entre elles, nous proposons ensuite une brève solution.

1) Laisser le travail déborder sur le sprint suivant

La première erreur est à mon avis l'une des pires habitudes qu'une équipe puisse développer : laisser le travail déborder d'un Sprint sur le suivant.

Cela se produit lorsqu'une équipe ne termine pas tous les Product Backlog Items prévus pour un Sprint et emporte simplement ce travail dans le Sprint suivant.

Ne me comprends pas mal : de temps en temps, il arrivera qu'une équipe ne termine pas tout. En fait, c'est même bon signe quand cela se produit parfois. Cela signifie que l'équipe se fixe un planning ambitieux et ne prévoit pas trop peu de travail pour un Sprint par peur de ne pas tout accomplir.

Cependant, un Scrum Master ne devrait pas non plus considérer comme anodin le fait qu'une équipe ne termine pas le travail prévu, sinon les Sprints deviennent des limites artificielles et dénuées de sens. Les équipes devraient ressentir une légère pression à l'approche de la fin du Sprint. Une équipe devrait se dire : « Oh, le Sprint se termine demain. Je dois vraiment rester concentré aujourd'hui et finir. »

Si le débordement de travail sur le Sprint suivant est un problème dans ton équipe, il y a plusieurs choses que tu peux faire :

Premièrement, tu dois te débarrasser de cette mauvaise habitude. Encourage les membres de l'équipe à planifier leur prochain Sprint de manière à pouvoir définitivement terminer tout le travail. Cela signifie qu'ils devraient y aller doucement et planifier le prochain Sprint avec prudence. Si tout se passe bien, plus de travail pourra être ajouté au Sprint.

De plus, tu peux essayer de faire en sorte que l'équipe ressente un petit sentiment de culpabilité quand tout n'est pas terminé. Il ne s'agit pas que quelqu'un se sente vraiment mal. Les membres de l'équipe devraient juste avoir un peu mauvaise conscience, comme moi en ce moment. J'essaie de boire moins de sodas. Je fais déjà des progrès et je n'en ai pas bu depuis une semaine. Mais aujourd'hui, en écrivant cet article, j'en avais envie. Alors je me suis accordé un soda. Je ne me sens pas mal pour autant, mais je ne veux définitivement pas en boire un autre demain pour ne pas retomber dans mes vieilles habitudes.

2) Réalisation des Daily Scrums

Une deuxième erreur que j'observe fréquemment chez les Scrum Masters est qu'ils prennent en charge l'animation du Daily Scrum. Bien sûr, le Scrum Master devrait participer aux Daily Scrums et donner lui-même une mise à jour. Cependant, le Scrum Master n'a pas besoin de diriger la réunion pour inciter constamment les membres de l'équipe à participer, etc.

Le Scrum Master devrait expliquer les règles et la raison d'être du Daily Scrum, animer les deux ou trois premières réunions et encourager les gens à participer. Ensuite, il devrait laisser l'équipe conduire elle-même les Daily Scrums.

Les activités d'un Daily Scrum ne sont pas particulièrement difficiles. On n'a pas besoin d'un « policier » qui régule tout, car si le Scrum Master animait la réunion de cette manière, la discussion serait trop centrée sur le Scrum Master.

Avec une nouvelle équipe, j'aime commencer en animant définitivement les premières réunions moi-même. Puis à un moment donné, je dis simplement « OK les amis, il est temps de commencer » et je demande peut-être qui veut commencer. Mais bientôt, j'arrête aussi de faire ça.

Après quelques réunions, je commence alors à regarder ostensiblement ma montre quand il est temps de démarrer la réunion. Si nécessaire, je me racle la gorge assez fort pour que tout le monde comprenne ce qui se passe. Et puis je reste simplement là, immobile, jusqu'à ce que quelqu'un dise : « Oh, je crois qu'on devrait commencer. » Après quelques jours à regarder ma montre et à me racler la gorge, je vais encore plus loin et je regarde seulement ma montre quand il est temps de commencer. Et après encore quelques jours, j'arrête même de faire ça. Je reste simplement là et j'attends que la réunion commence.

Bien sûr, je ne reste pas silencieux pendant toute la réunion. Il peut arriver que je doive coacher quelqu'un pour qu'il entre plus dans les détails, ou j'interromps poliment quelqu'un et suggère qu'on pourrait peut-être aborder les détails après le Daily Scrum.

Imaginez simplement que moi (ou une autre personne extérieure) assiste à votre Daily. Dans ce cas, on ne devrait pas pouvoir deviner qui est le Scrum Master de l'équipe simplement en observant. Il arrivera certainement de temps en temps que le Scrum Master dise quelque chose que seul un Scrum Master dirait. Mais cela ne devrait pas se produire constamment.

3) Laisser l'équipe foncer droit vers le burnout

Je ne suis pas particulièrement fan de la plupart des termes Scrum, mais le terme Sprint est particulièrement problématique. Quand je sprinte en courant, je me fatigue rapidement et je dois faire régulièrement des pauses. C'est une métaphore assez mauvaise pour une équipe.

Un Sprint se termine et le suivant commence. Les équipes ne devraient pas commencer le Sprint suivant alors qu'elles sont encore en train de récupérer du précédent. Au contraire, les équipes devraient travailler à un rythme soutenable, rendu célèbre par Kent Beck sous le nom de Sustainable Pace.

La troisième erreur que je vois souvent, c'est que les Scrum Masters laissent leurs équipes dépasser ce rythme soutenable et se diriger vers un burnout. Un bon Scrum Master devrait être vigilant et protéger l'équipe d'un éventuel burnout.

Beaucoup d'équipes sont optimistes et cet optimisme se répercute sur la quantité de travail qu'elles prévoient pour un Sprint. Les Scrum Masters devraient être sur leurs gardes et conseiller la prudence aux équipes lorsqu'elles risquent, lors du Sprint Planning, de s'engager sur plus de travail qu'elles n'en ont accompli lors des Sprints précédents. Pourquoi ? Parce que même si tout le travail peut être terminé dans le Sprint, l'équipe risque de commencer le Sprint suivant épuisée et avec trop d'optimisme concernant la quantité de travail. À un moment donné, l'équipe ne pourra plus maintenir un rythme soutenable et s'épuisera. Une bonne façon de protéger une équipe de cette situation est de lui créer des espaces de liberté où elle peut décider elle-même sur quoi elle veut travailler.

6 x 2 + 1

Pour cela, j'aime utiliser une méthode que j'appelle « 6 x 2 + 1 ». Cela correspond à six Sprints de deux semaines plus un Sprint d'une semaine tout à la fin. Les membres de l'équipe peuvent alors choisir eux-mêmes sur quoi ils veulent travailler pendant ce dernier Sprint. Certains utilisent ce temps pour leur développement personnel (lire un livre, suivre une formation vidéo, etc.). D'autres utilisent ce temps pour refactorer du code peu élégant que le Product Owner n'a pas priorisé. D'autres membres de l'équipe tentent peut-être une expérimentation qui pourrait, selon eux, mener à une nouvelle fonctionnalité géniale. Tout cela, l'équipe peut le décider entièrement par elle-même.

Introduire un tel cycle peut cependant avoir encore bien d'autres avantages. Le Product Owner dispose ainsi par exemple d'une semaine entière sans être « dérangé » par l'équipe. Et c'est souvent le meilleur argument de vente pour convaincre un Product Owner.

Ce cycle peut également être avantageux pour toute l'organisation lorsqu'il faut prendre des engagements comme par exemple « Nous devons livrer cette fonctionnalité dans 3 mois ! » La 13e semaine des Sprints 6 x 2 + 1 peut aussi être utilisée pour un Sprint normal si l'équipe a pris du retard par rapport à une deadline. Si l'équipe parvient ensuite à respecter la deadline, on peut toujours lui accorder un Sprint d'une semaine à sa libre disposition.

Apprends-en plus sur ces points dans nos formations pour Scrum Master et deviens opérationnel dans ce rôle agile en trois jours, tout en apprenant à assumer tes responsabilités en tant que Servant Leader.