Press "Enter" to skip to content

Trucs de Scrum Master

Je n’ai pas honte de partager mes secrets les plus inavouables

Je vous propose un cahier de recettes de grand-mère du Scrum Master. Vous trouverez ici des trucs et astuces qui aideront le Scrum Master débutant et moins débutant.

Bonne lecture !

“Agile c’est expérimenter en permanence…”

Parfois, l’équipe n’a pas envie de mettre en place certaines pratiques dont elle a vraiment besoin. Voici une méthode subtile pour y arriver malgré tout :

“Allez, on essaie ça. C’est ça faire de l’Agile, hein, c’est toujours essayer des nouveaux trucs. On débrieffera en Rétro.”

D’ici la Rétro, tout le monde aura oublié de contester.

Vous avez le mandat de Scrum Master. Utilisez-le.

Variante moins subtile : vous imposez. En soi, vous êtes le Scrum Master, vous avez la légitimité, on ne peut pas vraiment vous dire non.

Bien entendu, il faut faire attention à ne pas abuser de ce moyen : si cela peut vous servir à faire avancer une équipe pas très mature, n’oubliez pas que votre but à terme est d’avoir une équipe auto-organisée. Imposer des choses va à contre-sens, mais ça peut débloquer des situations.

Un process = un support

Utilisez un board ou n’importe quel autre support physique et visuel dès lors que l’équipe se donne un nouveau process mais ne le respecte pas.

Exemples de situations :

On dit de faire le stand-up différemment, mais l’équipe continue sur la même routine.

Une procédure de mise en production est définie, mais pas mise en place.

Le Definition of Done est mis à jour, mais on découvre toujours les mêmes trous en fin d’itération.

Organiser la Rétro

La Rétrospective est un de vos outils de base. L’organiser et construire son format n’est pas anodin.

En effet, vous étiez là durant toute l’itération, vous avez déjà votre petite idée de ce que vous aimeriez que l’équipe remonte et mette en place comme actions.

Vous allez donc réfléchir au format pour justement orienter l’équipe et faire ressortir les choses importantes.

Une forme de manipulation ? Peut-être. Mais si ça aide l’équipe…

Et au final, c’est quand même eux qui vont décider des actions. Vous ne forcez rien.

“La Rétro ne sert à rien.”

L’équipe n’est pas convaincue de l’intérêt de la Rétro ? Ils ont bien raison !

Tirez parti de leur scepticisme et demandez-leur donc comment nous pourrons mesurer :

  • Que l’action a bien été mise en place
  • Que l’action améliore effectivement la situation d’origine

Nous définissons une action pour répondre à un besoin ou un problème. Quel était ce besoin ou ce problème ? Comment mesurer que ce besoin est maintenant rempli ou que ce problème est résolu ? Ou du moins, que nous sommes sur la bonne voie ?

Et bien sûr, ensuite : faites-le. Mesurez !

“On est bloqué par une dépendance externe”

Voici une phrase que j’aime bien dire :

Pour prendre le temps de quelqu’un, il faut perdre le sien en même temps.

Vous seriez étonné de ce que vous êtes capable d’accomplir en allant voir les gens. N’oubliez pas qu’ils sont eux aussi très occupés, et ont beaucoup d’autres choses à faire. Dans tous les cas, c’est ainsi que vous devez penser.

Si vous allez physiquement les voir, souvent, très souvent, vous arriverez à débloquer les choses — sans escalade hiérarchique. N’hésitez pas à rester à côté d’eux, à leur poste de travail. Surtout, soyez patient et non invasif. Faites juste acte de présence jusqu’à ce que votre tour arrive et qu’on puisse s’occuper de vous. Même si c’est long.

Et oui, en tant que Scrum Master, votre temps est fait pour être gâché. Mais ça fait avancer votre équipe !

“Tous les problèmes viennent d’en dehors de l’équipe”

Classique de l’équipe débutante, on ne voit que les problèmes en dehors de l’équipe. Ce qui donne une excuse bien commode : on ne peut rien faire ! Pas vrai ?

Voici une autre phrase que j’aime bien dire :

Si le sujet était vraiment important pour vous, vous passeriez votre propre temps dessus.

Si c’est un problème pour vous, passez du temps dessus ; vous pouvez certainement au moins en minimiser l’impact à défaut de corriger le problème.

Si le problème ne vaut pas vos propres efforts, ne vous attendez pas à ce que vos partenaires ou le reste de l’organisation fasse quoi que ce soit.

Voter anonymement de comment on vote

Je vous souhaite de ne pas avoir besoin de ce conseil…

Imaginez-vous fraîchement arrivé dans votre nouvelle équipe. L’ambiance est un peu tendue. Déjà, votre sens aigu de l’empathie vous fait remarquer que tout le monde n’est pas hyper motivé. Vous suspectez même que l’influence du “management” pour ne pas dire “les Chefs” est très forte.

Mais arrive le temps de la Rétro ! Je vous entends déjà vous dire : “Le moment idéal pour faire un point sur tout cela et faire surfacer ces problèmes !”

Quelle erreur ! Vous êtes bien naïf mon cher ami…

Ne pré-supposez pas que l’ambiance est toujours saine et constructive, que chacun est libre de s’exprimer. Que règne cette fameuse bienveillante.

Si vous avez le moindre doute, cela peut valoir le coup de faire par exemple un petit Explorer, Shopper, Vacationer, Prisoner pour situer l’état d’esprit de l’équipe.

Mais surtout : procédez au vote de manière anonyme. Sinon, ceux qui ne se sentent pas libres de parler, ne répondront pas honnêtement. Sur le papier, tout ira dans le meilleur des mondes alors que pourtant, une fois sorti de la Rétro et revenu dans le monde réel, c’est tout l’inverse que vous ressentirez.

On en arrive au paradoxe apparent du titre de ce truc : avant de procéder à un vote, il faut d’abord voter anonymement de comment on vote : vote-t-on anonymement ou non ?

Oui c’est relou. Mais vous avez rejoint cette équipe pour être en vacance ou pour les aider ?

Une estimation reste une estimation

Les estimations de l’équipe sont, comme le nom l’indique, des estimations. C’est à dire : tout sauf une promesse. Ce sont des projections totalement hypothétiques sur un avenir incertain à partir d’informations partielles.

Donc :

  1. On se rate dans les estimations, c’est normal, c’est le concept même.
  2. Ca ne sert à rien de se prendre la tête sur des estimations. Ce ne sont que des estimations.

Estimer, oui. Perdre son temps, non. Construire le produit a plus de valeur qu’estimer le temps que cela prendra. Alors estimez vite.

Utilisez la vélocité à bon escient 1/2

À quoi ne sert PAS la vélocité ?

Première erreur classique : déterminer l’engagement de l’équipe à chaque itération en se basant sur la vélocité.

L’équipe n’a pas besoin de vélocité pour définir le périmètre du backlog qui est embarqué dans l’itération. L’équipe doit simplement se projeter sur le périmètre en question et définir si ça tient ou non ; et ajuster en conséquence le périmètre.

Si l’équipe n’y arrive pas, procédez au découpage en tâches techniques, ce qui rendra le périmètre beaucoup plus concret. Éventuellement, estimez les tâches techniques en temps. Tenez compte de qui sera absent, de quelles compétences seront nécessaires et disponibles pendant l’itération. Si nécessaire, faites une projection de l’itération, jour par jour.

C’est une étape passagère. Très vite, l’équipe va se faire à cette manière de travailler et n’aura plus besoin d’aller autant dans le détail.

La vélocité sert à avoir une idée de quand sortiront les choses. Rien d’autre.

Utilisez la vélocité à bon escient 2/2

À quoi d’autre ne sert PAS la vélocité ?

Seconde erreur classique : déterminer si l’équipe s’améliore en traçant l’évolution de sa vélocité.

C’est une très mauvaise idée.

D’abord parce que cet indicateur ne sera pas représentatif pour tout un tas de raisons. Voici une liste non exhaustive d’évènements qui vont impacter significativement la vélocité, en positif ou en négatif, sans que l’on puisse faire pour autant un lien direct avec l’évolution de la productivité de l’équipe :

  • Membres de l’équipe qui partent, nouveaux membres qui arrivent
  • Nouvelles technos que l’équipe ne maîtrise pas encore, ou anciennes technos que l’équipe maîtrise désormais à la perfection
  • Interférences extérieures, sujets urgents à traiter en prod (urgents mais justifiés)
  • Evolution du niveau d’exigence de qualité de l’équipe : les développements sont plus couteux
  • Et justement on crée et donc on traite moins de bugs

Mais ensuite et surtout parce que si vous utilisez la vélocité comme indicateur de performance de l’équipe, vous risquez d’impacter négativement le fonctionnement de l’équipe en les faisant se concentrer sur les points de la vélocité plutôt que sur le produit.

Supposons que le but de l’équipe soit de livrer le plus de points possibles. Voici quelques astuces pour l’équipe :

  • Accumulons la dette technique. On ne sera plus là pour vivre avec !
  • La correction de bugs est comptée dans la vélocité ? Alors plus de bugs = plus de points — créons plus de bugs !
  • Restons sur les technos qu’on connait et maîtrise déjà, pour ne pas perdre de temps à apprendre de nouvelles choses
  • Il y a trop de réunions, j’ai du code à écrire moi ! Expédions la Rétro, les actions de Rétro ça ne compte pas dans la vélocité
  • Une grosse fonctionnalité inutile rapporte plus de points qu’une modification minimaliste qui répond au besoin du client
  • Estimons les US à la hausse, comme ça on sortira plus de points !

La mesure de la vélocité doit être neutre, hors de l’équipe. On n’utilise pas cette mesure pour noter la performance de l’équipe.

Pour l’équipe, c’est comme si dans le cadre de l’itération les points n’existaient pas. C’est un outil uniquement utilisé à des fins de vision produit et release.

N’estimez pas pour estimer !

Mais au fait pourquoi on estime ?

Pour pouvoir construire des plans de release, pour pouvoir gérer des dépendances entre plusieurs équipes.

Posez-vous la question : avez-vous ce besoin ?

Si vous ne faites pas de telles projections sur l’avenir, ou si vous les faites sans utiliser les points et la vélocité, alors toutes ces estimations de vous servent à rien. C’est du déchet comme on dit en Lean. Ce qui compte, c’est la valeur que sort l’équipe : du code en production, fonctionnel, et qui répond à un besoin.

Bien sûr, l’équipe doit continuer de découper les US jusqu’à ce qu’elles soient “suffisamment petites” (le S de INVEST). Mais pas besoin de mener le travail d’estimation plus loin que le découpage.

Estimez parce que c’est utile, pas parce que c’est la méthode.

Si vous devez estimer, estimez-bien

Lors d’un grooming ou refinement, l’essentiel des discussions devraient tourner autour du fonctionnel.

Quand on estime, on ne devrait pas se focaliser sur la technique — sauf s’il s’agit d’une décision avec des impacts forts sur le fonctionnel, ou sur le chiffrage.

N’hésitez pas à recentrer le débat sur le fonctionnel. Aussi souvent que nécessaire. C’est la responsabilité numéro 1 du Scrum Master pendant ce type de réunion.

Ne pas comprendre la technique, c’est un atout

Un des rôles-clef du Scrum Master, c’est le facilitateur.

Et être facilitateur, c’est avant tout être neutre.

Ainsi, ne pas comprendre la technique, vous pouvez en faire un atout : moins vous comprenez de quoi on discute, moins vous serez tenté de vous impliquer dans la discussion. En d’autres termes : plus il vous sera facile de rester neutre.

Concentrez-vous donc alors sur le ton utilisé, sur le temps passé sur les sujets. Les personnes se comprennent-elles ? Est-ce qu’on avance ?

Puis réagissez, et sauvez la réunion.

Un stand-up s’anime sans comprendre de quoi parle l’équipe

Comment animer un stand-up si on ne comprend pas de quoi parle l’équipe ?

En se mettant des petits indicateurs agnostiques des sujets et de la technique !

Par exemple en faisant évaluer à l’équipe le temps qu’ils pensent passer sur chaque tâche technique, et en bornant le temps maximum, disons à 2 jours. Puis en stand-up, faire noter le temps passé sur les tâches. Voilà un indicateur permettant de détecter un potentiel blocage !

Autre exemple : se reposer sur les priorités. Le backlog d’itération est priorisé. Il est donc simple de détecter lorsque l’équipe se met à travailler sur des US moins prioritaire, ou lorsqu’elle commence trop d’US en parallèle.

Et tout ça sans avoir besoin de lire ni de comprendre le moindre post-it !

Poser des questions qui n’en sont pas… ou l’art de convaincre

Parfois vous êtes sûr de vous, vous savez ce qu’il faut faire. Mais la mise en place ne dépend pas que de vous. Alors comment convaincre ?

En posant une question. Une fausse question, bien sûr, puisque votre but n’est pas d’avoir une réponse. Non ce qui vous intéresse, c’est de provoquer un déclic. Faire en sorte que votre interlocuteur arrive à la même conclusion que vous.

Vous n’y croyez pas ? Essayez, vous verrez : tout le monde n’y verra que du feu et essaiera de vous répondre. Ce qui enclenchera un processus de réflexion… processus que vous aurez à peine orienté.

Et, qui sait, vous pourriez même être surpris de ce qui sort de cette réflexion.

Ignorez les points pendant l’itération

Ohlà, ça fait déjà longtemps que je suis sur cette US à 1 point… Il faut que je me dépêche !

NON. Il faut faire le travail bien, et ne jamais rogner sur la qualité. On s’est raté dans l’estimation, bah ok ce ne seraient pas des estimations si on tombait juste à chaque fois.

Cool ! J’ai déjà fini cette US à 8 points. Je vais en profiter pour nettoyer plein de trucs autour de ça et écrire quelques tests, on de la dette technique qui traine…

POURQUOI ?

  • Écrire du code propre, couvrir la fonctionnalité de tests, et ne pas laisser s’accumuler la dette technique : tout ça n’est pas déjà dans la Definition of Done de l’équipe ? En quoi cette US est-elle différente ? On ne le fait pas d’habitude ???
  • Franchement, si vous avez torché la fonctionnalité, c’est cool non ? Pourquoi ne pas passer à la suite ? Ne vous inquiétez pas, vous trouverez bien de quoi vous occuper en fin d’itération si vous avez de la marge.

Ignorez purement et simplement les point pendant l’itération. Les points ne servent qu’à faire des roadmaps. À la rigueur pour tracer le burndown, et encore est-ce que juste tracer le burndown en nombre d’US ne suffirait pas ?

Dégagez le burndown d’itération s’il est détourné par l’organisation

Le burndown d’itération ne sert qu’à l’équipe de développement. Personne ne peut venir et demander des comptes à l’équipe sur la base de cette courbe. Si c’est le cas… débarrassez-vous en. C’est que votre organisation n’est pas prête pour cela.

Ah, et au fait : bon courage pour la suite dans cette organisation.

À quoi sert le burndown d’itération

Et donc, comme l’équipe de développement s’en sert-elle ? Pour poser des questions. Poser le genre de questions que poserait le Scrum Master s’il était là et qu’il regardait le board.

Dites donc, on a démarré un paquet d’US mais on n’en a pas terminé beaucoup… On se recentre les gars ?

Hum, on a beaucoup de tâches techniques en cours. Et si on arrêtait de développer pour dejà finaliser tout ça ?

Zéro flicage. Aucune accusation. Juste un état de fait, qu’on constate, et qui challenge comment l’itération se déroule.

Et surtout, un moyen d’éviter de se rendre compte de tout cela le dernier jour de l’itération, quand on n’a plus le temps de rien faire pour corriger le tir.

Cet article vous a plu ?

  • Cliquez sur le cœur pour m’encourager, et partagez l’article autour de vous
  • Abonnez-vous à mon profil via le bouton Follow
  • Consultez mes autres articles sur le thème du rôle du Scrum Master !

Laisser un commentaire

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

Top