Pratiques pour un Standup Meeting réussi

Dans une équipe produit, le travail de chacun est constamment modifié par les autres, personne ne travaille en isolation. Il y a un besoin vital de partager les informations de ce qui est en train d’être créé ou modifié le plus tôt possible.

Le DSM (Daily Standup Meeting) est une bonne solution, si et seulement si on s’en sert comme un point de synchro, pas comme point de contrôle.

Tirer le meilleur du DSM

Il m’est arrivé de me retrouver dans des situations où je ne tirais aucune valeur du DSM : Dans une mission où on était 30 à faire notre daily reporting au chef de projet. Dans une autre où on avait remplacé le DSM par un email quotidien dans lequel on donnait nos 3 réponses. Et une autre boite avec une équipe distribuée où chacun répondait aux 3 questions sur skype avant de mettre en mute pour continuer tranquillement à faire ce qu’ils faisaient.

Le point commun de chacune de ces situations est évident : aucune synchro, que du reporting.

Pour une synchro efficace, le plus important dans le DSM, ce n’est pas de dire, mais d’écouter. Et, vous allez voir, le rôle du scrum master c’est de “super écouter”.

De quoi doit on parler ?

Les trois questions

Il y a les fameuses 3 questions : qu’est ce que j’ai fait hier, qu’est ce que je compte faire aujourd’hui, est ce que j’ai un problème ?

Des fois, pour orienter l’équipe vers plus de fluidité, on peut souhaiter ne parler que de ce qui a bougé dans le board : “qu’est ce que j’ai fait hier” devient “qu’est ce que j’ai fini hier”. Ça a plus de force, mais ça n’a de sens que si les stories sont suffisamment bien découpées.

Je n’aime pas trop être contraint par ces questions et encore moins par la règle des “1 min par personne”, je trouve que ça laisse peu de place à l’échange et qu’il y a trop de risques de passer à côté d’informations importantes. Mon approche ici, et en général, c’est de laisser de la liberté en premier, et d’ajouter des contraintes si besoin.

Parlez de tout

Quelque soit le format du DSM, il faut faire attention à parler des tâches projet (dans le board) et des tâches annexes (amélioration continue).

Si jamais vous avez fini votre DSM et qu’une des tâches n’a pas été mentionnée, c’est un problème. Est ce qu’il y a un blocage ? Ou si personne ne travaille dessus, pourquoi traite-t-on des stories moins prioritaires ?

Souvent on maintient une zone différente (board ou todo liste) avec les actions et tâches d’amélioration continue. Si on n’en parle jamais pendant l’itération, on augmente le risque de ne jamais travailler dessus et de se retrouver à la prochaine rétrospective sans avoir avancé.

Allez plus loin

J’aime aussi ouvrir le DSM à l’extérieur de temps en temps. C’est important de se connecter au reste de l’entreprise quand on est dans une équipe produit.

Une façon simple et conviviale est d’inviter une fois par semaine quelqu’un d’extérieur à l’équipe mais impliqué dans le projet (utilisateur, expert métier, manager, membre d’une équipe connexe…). C’est une bonne occasion de resserrer les liens, de faire un petit peu de com’. Mais pour ça il faut relâcher un peu les contraintes pour ne pas le perdre : soyez peut être un peu moins rigide sur le format ou moins technique sur le contenu.

N'hésitez pas à proposer à cette personne de rester après le DSM, pour un petit dej et une session sur un poste de démo.

Il arrive aussi régulièrement que les développeurs aient besoin d’avoir une discussion technique à propos d’un sujet du jour. Dans ces cas là il est recommandé de faire ça dans un second temps, quand le reste de l’équipe est partie. Profitez en pour sortir le whiteboard et les cafés, généralement ça fonctionne mieux.

A quoi faire attention ?

Le DSM dans Scrum est assez prescriptif : 3 questions, 15 minutes, seulement les membres actifs de l’équipe. Ces limitations forcent en général les participants à se concentrer sur ce qu’ils vont dire, au point de ne pas réellement faire attention à ce que disent les autres.

Savoir de quoi parler, c’est la partie facile. Pour bien se synchroniser, il faut savoir aussi quoi écouter.

Le tunnel

Lors du DSM, si vous vous rendez compte qu’un membre de l’équipe passe beaucoup de temps sur une même tâche ou story, il faut le mentionner.

En soi, ça n’a pas l’air grave, mais c’est en fait un symptôme de plusieurs problèmes possibles : soit la story est trop grosse, soit elle est mal estimée, soit la personne fait du hors sujet, soit la personne est coincée.

Plus on repère ces problèmes tôt, plus il est facile de les régler.

Le multi-tâche

Vous devez aussi vous rendre compte si quelqu’un travaille sur plusieurs tâches ou stories en même temps.

Ça peut masquer un blocage qui n’a pas été mentionné. Et du coup plutôt que d’essayer de débloquer la story la plus prioritaire, la personne va contourner et travailler sur une moins importante, c’est un problème.

Ça peut aussi vouloir dire que le découpage est mal fait. Ou qu’une généralisation (ou factorisation) est faite trop tôt. Ou enfin qu’on a à faire à quelqu’un qui commence mais ne finit pas.

Tous ces sujets doivent être remontés en DSM pour pouvoir être traités au plus tard en rétro.

Les retours

Si vous avez un nombre anormal de retours sur une même story, quelque soit l’étape, il faut un temps mort afin de baisser le niveau de stress et de mettre plusieurs têtes sur le problème.

Proposez d’en parler après le DSM, pour comprendre les causes et tenter de comprendre comment éviter de se retrouver dans cette situation à l’avenir.

Le problème récurrent

Un problème est remonté en DSM, mais ce n’est pas la première fois. Ne faites pas l’erreur de vous y habituer. Au contraire, plus il y a d'occurrences, plus la criticité de ce problème augmente !

Les problèmes qui rapportent le plus à traiter sont ceux qui vous font perdre régulièrement du temps.

Le niveau d’énergie de chacun

Enfin, c’est un bon moment pour avoir un peu d’empathie et de regarder autour de vous : comment se sentent vos coéquipiers ? Est ce que quelqu’un est fatigué ? En colère ? Désengagé ou désintéressé ? Ou au contraire en forme ou content ou fier d’avoir terminé quelque chose ?

J’aime bien faire la pause café après le DSM, ça nous permet de revenir de manière informelle sur ces niveaux d’énergie et de pouvoir débloquer des crispations ou de célébrer ensemble les bonnes nouvelles.

Le rôle du coach ou scrum master

En tant que coach ou scrum master, votre rôle n’est surtout pas de vous impliquer et de régler les problèmes : vous devez entraîner votre équipe à le faire, à écouter et réagir.

En fait, on peut dire que votre rôle c’est de super écouter : d’écouter le reste de l’équipe écouter. Vous devriez intervenir en fin de DSM s’il le faut pour dire “j’aurai aimé que l’un de vous remarque ça”.

Votre rôle est d’apprendre aux autres à écouter plus que dire, et réagir aux signaux pour vraiment être synchronisés.

N’hésitez pas à provoquer l’écoute, à mettre en évidence les signaux. J’ai vu un scrum master commencer chaque DSM par un tour de “mood”, pour faciliter la discussion sur les niveaux d’énergie de chacun.

Dans un contexte où le tunnel était fréquent, on a compté visuellement les jours passés sur chaque tâche de manière à forcer la discussion. Pareil pour les retours.

L’objectif est de rendre l’équipe autonome et de leur permettre d’utiliser le DSM pour savoir qui fait quoi, mais aussi pour apprendre à voir les problèmes au plus tôt et d’y réagir.

Bonus

En bonus, voici une question qu’un manager m’a posé, un jour, en entretien, et la réponse que je donnerai aujourd’hui (qui n’est pas celle que j’ai donnée à l’époque) :

“J’ai un développeur qui arrive systématiquement en retard de quelques minutes au DSM. On l’a décalé de 15 minutes pour lui, et il continue à arriver en retard. Qu’est ce qu’on fait ?”

C’est une situation classique, et j’ai aussi été ce développeur.

Aujourd’hui, je commencerais par essayer de savoir qui est gêné par ces retards.

Si la majeure partie de l’équipe est mécontente, ça veut dire qu’ils ont un problème mais qu’ils ne savent pas encore comment le régler dans l’équipe, eux-mêmes. Donc il faudrait les aider sur la résolution de problèmes en groupe de manière non violente.

Si tout le monde s’en moque, alors ça veut dire que le DSM n’est pas si important pour eux. C’est le moment de creuser les raisons de leur désengagement et d’attaquer par là.

C’est possible que le DSM soit un daily reporting pour le manager et un point de contrôle pour s’assurer du respect des horaires. Dans ce cas, le gros du coaching doit être fait dans un premier temps avec le manager avant de pouvoir avoir des résultats avec l’équipe.

Enfin, si vous voulez supprimer le point de contention (le symptôme) en attendant que l’accompagnement fasse effet, vous pouvez toujours décaler le DSM à 11h45 :)