Comment gérer les retards au Daily Standup Meeting (DSM) ?
Dans ma vie rêvée de Scrum Master, je suis parfois confronté à un membre de l’équipe qui arrive régulièrement en retard au Daily Standup Meeting. Je l’appelle le Serial Later.
Ceci est une histoire vraie.
Pour un nombre incalculable et fleuri de raisons, le retard arrive. Les transports en commun, mêmes les ascenseurs, ont alors bon dos.
Pourquoi, cependant, certains sont plus souvent en retard que d’autres ?
Les Serial Later me rendent perplexe. Nous sommes une équipe efficace développant des superbes innovations dans le cadre d’une excellente mission.
Et les retards de mon Serial Later continuent à mettre en danger ce collectif !!
Expliquer l’intérêt du DSM
Au bout de quelques retards consécutifs, c’est une bonne occasion de rappeler les conséquences de ne pas être à l’heure et de ne pas être prêt à chaque DSM. Voici les bienfaits qu’un DSM peut procurer aux membres de l’équipe:
- Le temps est précieux pour tous les membres de l’équipe, y compris celui du Serial Later,
- Atteinte du Sprint Goal favorisé: Le Serial Later n’a pas les informations nécessaires pour bien effectuer sa journée, les autres membres de l’équipe peuvent louper des informations importantes,
- Les échanges se font durant le reste de la journée sans le reste de l’équipe.
C’est l’application de la technique: Faits/Observations (les retards), Effets (conséquences), Qu’est-ce qu’on fait (être à l’heure ?) et les Bienfaits qu’on peut collectivement et individuellement atteindre si tout le monde est à l’heure et est prêt pour le DSM.
Malgré cela, la compréhension partagée de l’intérêt du DSM ne suffit pas. Comment faire adhérer mon Serial Later ?
Le management visuel est-il utilisé correctement ?
Je me suis aperçu que j’étais probablement trop l’intermédiaire pour utiliser notre Scrum Sprint Board (Un Kanban de Sprint + Burndown associé).
Ce n’est pas très agile. Ça ressemble à un process de préférence à une interaction. Le manifeste agile c’est quand même plein de bon sens.
Je choisis alors d’enseigner l’usage de notre management visuel afin que les membres de l’équipe puissent comprendre l’importance de l’utiliser lors du DSM.
Comment ? En expliquant les conséquences concrètes d’un board non à jour:
- 2 personnes peuvent se mettre sur la même tâche lorsque la tâche reste dans la colonne “à faire” alors qu’un contributeur est en cours dessus,
- Livraison sans une US dans la note de livraison car un contributeur a oublié de le mettre à Done et qu’il est en congés.
Le message : le management visuel est votre outil d’auto-organisation. Si vous ne le mettez pas à jour, vous n’êtes pas transparent avec le reste de l’équipe. La transparence est bien l’un des piliers de Scrum. L’auto organisation est un but à atteindre.
Si tous les membres de l’équipe ne sont pas prêts pour des DSM efficaces alors quelqu’un doit faire le secrétaire. Au mieux c’est le SM, au pire c’est le PO. Nous sortons de notre cadre agile. Le job est moins intéressant pour tout le monde. Les performances du collectif baissent.
Mes efforts ont un effet et nous sommes plus transparents sur notre capacité à atteindre nos Sprint Goals depuis.
Malgré cela, les retards continuent. La cause racine n’est pas encore identifiée.
Problèmes personnels
Mon Serial Later a la transparence de dire dans l’open space, “As tu des conseils à me donner parce que je me sens fatigué, en déprime passagère. C’est l’automne après tout.”
Il existe toutes sortes de raisons pour qu’un membre de l’équipe ne soit pas au meilleur de sa forme, la famille, un festival …
Je tiens peut-être la cause racine ?
En tant que coach sportif en dehors du travail, c’est un domaine que je connais, la gestion de l’énergie, de l’équilibre, etc.
Je lui suggère des conseils simples pour s’équilibrer : Respiration, Alimentation, Sommeil, Sport. Le lendemain, il me dit “j’ai fait du sport hier.” Je crois alors que c’est gagné ! Je tiens ma raison et il semble ouvert à la gestion de son énergie.
Malheureusement, les retards continuent.
DSM: reporting ou vraie instance d’inspection du Sprint Goal ?
Est-ce que les informations échangés en DSM sont si utiles ? Au final, cela faisait longtemps que nous jouions le format «Ce qu’on a fait hier», «Ce qu’on va faire aujourd’hui» et «Quels sont les obstacles ?».
Nous faisions plutôt du reporting sans nous focaliser sur des échanges vraiment utiles.
Nous expérimentons alors un nouveau format. Nous l’accompagnons d’une planche de facilitation graphique pour aider à la compréhension.

Les dernières recommandations du Scrum Guide indique qu’il est préférable de parler du Sprint Goal. Nous tentons !
Ça stresse mon PO qui s’en servait suffisamment discrètement pour faire du reporting afin de relancer les devs pour savoir si le Sprint Goal allait être tenu.
En revanche, ça plaît beaucoup aux membres de l’équipe, il y a de vrais effets positifs. Les échanges sont de meilleure qualité.
Une autre illustration se met à tourner sur le bench : la loi des 2 pieds. Elle nous rappelle l’importance de se réunir dans le but d’échanger efficacement afin de réaliser un but commun engageant.

Néanmoins, les retards de mon Serial Later s’accumulent toujours. Damn !
Vision insuffisamment engageante ?
J’ai l’habitude de différencier ces 3 types d’engagements :
- l’engagement à être au rendez vous pour une date, si c’est une vraie date pour le produit, c’est plein de valeurs, ça engage l’équipe et ses membres. En revanche si ce sont des dates qui mettent en échec l’équipe, cela montre que nous préférons contractualiser plutôt que de collaborer avec les métiers. Nous ne sommes pas dans la préférence du manifeste agile,
- l’engagement d’une équipe à tenir un Sprint Goal. Il est primordial, car il tire une préparation en amont afin de réussir les Sprint Plannings et Revues de Sprint associés. Quand l’équipe maîtrise ses Sprint Goals, le chemin vers la vision est plus prédictible Sprint après Sprint,
- l’engagement d’un membre de l’équipe dépend de ses motivations intrinsèques (sens, maîtrise et autonomie). Si la mission n’a pas de sens à ses yeux, si il n’a pas les compétences nécessaires pour remplir sa mission, si il ne ressent pas suffisamment d’autonomie dans ses choix, alors son engagement baisse.
Est-ce que l’équipe et ses membres sont mis en échec ? Oui et oui, il y a des dates, régulièrement, et elles sont ouvertement décidées par le métier avec des marges de sécurité. Des items du backlog restent alors plusieurs sprint après sprint en échec. Le métier dit “cela fait pourtant plusieurs sprint qu’on les a priorisées et elles ne sont toujours pas prêtes”.
Nous sommes donc en échec sur certains items du backlog et ça peut miner la motivation de mon Serial Later. Il faut donc que cette mise en échec cesse.
Nous montons alors un point sur la préparation des Stories entre devs et PO, les choses se disent, c’est intense. Des actions concrètes sont décidées : mise en place de checklists qualité en amont du Sprint et l’application plus efficace d’une DoR (Definition of Ready). Ce n’est pas pour autant un contrat entre PO et Dev — pour ne pas préférer un contrat à la collaboration (manifeste agile).
L’effet est bénéfique sur les échanges en Sprint Planning et sur la vélocité de l’équipe.
Malgré tout, mon Serial Later est toujours en retard.
Compétences techniques suffisantes ?
Nous avons mis en place récemment des BBL (Brown Bag Lunch) hebdomadaires pour partager sur nos passions. Le principe est simple : entraîner vous à partager sur les sujets qui vous animent.
Mon Serial Later est un passionné de code, il a même des projets personnels avec plein de technos différentes. Je lui suggère donc d’animer un BBL sur son dernier projet perso.
Bingo, il profite de l’occasion ! Partager sa connaissance est un excellent moyen de vérifier qu’on maîtrise bien son sujet.
Mais, vous ne me croirez peut être pas, il a continué à être en retard !
Passer animateur de cérémonie
Plusieurs personnes de l’équipe se proposent d’animer une rétrospective avec des formats innovants dont mon Serial Later :
Bingo ! Ils animent les rétros et elles sont parfaitement énergisantes et engageantes avec des ROTI (Return On Time Invested) qui approchent du 5 !
Mais mon Serial Later est tenace, il continue à être en retard.
Je n’ai pas envie de perdre mon Serial Later, il me fait vivre une aventure enrichissante dans ma vie rêvée de Scrum Master.
Leçons apprises
En Scrum, le DSM est une instance d’inspection, elle doit être concise et efficace pour réussir Sprint Goal après Sprint Goal. Ces buts doivent idéalement s’inscrire dans une vision engageante afin de donner sens à chacun.
La maîtrise de chacun des contributeurs doit être développée via des instances d’apprentissage et une culture du Fail Fast parfaitement comprise par toute l’organisation.
Voici les instances d’apprentissage que vous pouvez facilement mettre en place à l’échelle de l’équipe : Priorisez des POC dans vos backlogs, ritualisez le partage, organisez des Hackathons régulièrement, favorisez les communautés de pratique entre devs.
Si vous arrivez à les généraliser à votre boîte ce sera d’autant plus efficace pour l’apprentissage de tous les contributeurs de toutes les Scrum Team.
Sur ce chemin, il est nécessaire de se rappeler les fondamentaux agiles afin d’obtenir l’engagement de chacun (Individus & Intéractions de préférence au process, Collaboration de préférence à la négociation contractuelle). Ils sont difficile à comprendre même après des années de pratique. Je ne peux que vous conseiller de les relire, de les enseigner, de les illustrer, de les raconter à votre équipe mais aussi à toutes les parties prenantes.
Tout ceci ne suffira peut être pas sur le court terme mais souvent, sur le moyen terme, cela paye : les Serial Later disparaissent d’eux-mêmes et l’équipe devient très performante.
Dans le cas du mien, il a fait tellement d’effort, qu’un jour ou moi même je me surprends à être en retard, je le trouve à animer le DSM avec un large sourire.
C’est ça ma vie rêvée de Scrum Master.
Je suis curieux de connaître vos techniques pour gérer vos Serial Laters.
