Pour préparer une session à Mix-It sur les daily standup meeting, j’ai mené une enquête sur la pratique du daily standup meeting.

Les 59 réponses proviennent d’entreprises variées : Sfeir, CarBoat Media, Ullink, Salesforce, Axa, startups et agences web. Je n’ai pas demandé le profil des répondants, mais en connaissant quelques uns, je peux dire qu’il y avait des développeurs juniors et expérimentés, des coachs, des scrumMasters et des product owners.

Commençons par les questions « faciles » : qui participe ?, quel est leur durée ?, avant de passer à des questions plus ouvertes sur les frictions et améliorations.

Y a-t-il des personnes qui ne sont pas développeurs ?

Quelle note mettriez-vous à votre standup meeting ?

Maintenant, je vous propose une sélection de réponses brutes, sans maquillage.

Vous êtes prêts ?

Qu’est ce qui fonctionne déjà bien ?

• La communication est bonne
• Partage des problèmes efficaces
• J’y apprends parfois que je peux aider sur une tâche et parfois une de mes demandes d’aide est entendue.
• Tout le monde participe
• Au moins car il a le mérite d’exister.
• J’y apprends tous les jours des infos utiles.
• Permet d’avoir de la visibilité sur le travail de chacun, identifier les points de blocage
• Parce que cette réunion me permet de savoir où en sont mes collègues et s’ils ont des difficultés. Ce qui est important pour moi.
• Il garde un intérêt pour avoir une vue globale sur ce qu’il y a à faire et voir les items avancer.
• La synchronisation de l’équipe est primordiale pour prendre les bonnes décisions de la journée. Je ne vois pas comment faire autrement.
• Efficace pour échanger : avoir un statut sur ce qui a été fait et comment on s’organise pour la journée.
• Inclut quelqu’un qui représente le métier et l’équipe de production.
• Quand il y a un vrai message à faire passer à l’équipe ou quand quelqu’un profite pour faire un appel à l’aide
• Ne dépasse pas 15 minutes
• Se focalise sur finir le travail ouvert.
• L’équipe suggère facilement des solutions

Qu’est ce qu’il faudrait pour que vous mettiez un 10/10 à votre standup ?

• Que les gens se perdent moins dans les détails. Plus de concision (réponse récurrente)
• Plus fluide et mieux timeboxer
• Plus rapide, plus synthétique
• Standup de 15 minutes max, où l’on ne parle pas pendant 15 minutes d‘un problème qui n’en vaut pas la peine. Le fait d’avoir une équipe distribuée n’aide pas
• Que le fond des discussions soient basées sur la valeur plus que sur les efforts produits.
• Dur à dire, peut être plus de régularité sur l’horaire ou une meilleure préparation de ce qu’on a à dire, mais c’est trop pénible à chaque fois, alors on continue d’improviser et de potentiellement oublier des choses.
• Parler davantage des problèmes restant à résoudre que de ce qu’on a fait
• Devrait être le déclencheur de prise de décisions communes et partagées
• Que ce ne soit pas un reporting vers le manager (les devs le regarde pendant qu’ils parlent, comme s’ils rendaient des comptes).
• Que les gens se souviennent de ce qui a été dit pendant plus de 5 minutes.
• Que les participants soient plus pro-actifs et impliqués
• Focaliser les discussions sur le projet de l’équipe et ne pas évoquer des activités sur d’autres projet. S’il y a besoin d’évoquer le travail sur d’autres projets, il est préférable d’organiser un standUp avec les personnes concernées.
• Que chacun y trouve réellement son intérêt et les trouvent utiles
• Tout le monde à l’heure
• Tour de table : l’équipe comprend les enjeux de la journée. Chacun sait comment y contribuer.
• Il manque beaucoup de choses. La plus importante : que les personnes soient présentes (sens core protocols)
• Que ça provoque des discussions et travaux communs après le standup
• Moins creuser les points de blocage immédiatement
• Tout le monde a été attentif, le programme de la journée est clair pour tous et personne ne part en se demandant comment il va réaliser ses tâches

Qu’avez-vous fait dernièrement pour améliorer votre daily ? Cela a-t-il fonctionné ?

• Timeboxer. Oui mieux. (réponse récurrente -> 5 fois, avec résultat probant)
• Temps de parole limité à une minute. Bof.
• Changer l’horaire. Oui.
• Remanier le board (repassage à Scrum après une période de Kanban) – pas spécifique au daily mais concerne plus le projet dans son ensemble. A redonné une vision et dynamisé l’équipe.  (réponse vue deux fois)
• Rajouter des indicateurs (vélocité, RAF, etc.)
• Mise en place d’un parking lot. Interdire de commencer à analyser les bugs en daily. Dire que chacun pouvait reprendre tout le monde sur le temps de parole. Le Daily a été ramené à 15 minutes.
• Rappel des règles, afin que les personnes parlent uniquement des infos nécessaires pour le travail du jour de l’équipe. Oui, ça a marché un temps.
• Le faire avant l’arrivée du manager -> non.
• On s’est mis à chronométrer le temps de parole pour éviter de partir dans des discussions trop longues. Si on déborde, c’est qu’on a un sujet à discuter et on le fait tout de suite après, uniquement avec les personnes qui se sentent concernées. Cela s’avère plutôt efficace et a redonné un peu plus de sens pour tout le monde à ce rituel matinal.
• Nous n’utilisons pas un tour de parole. Nous faisons le point story par story. On se concentre sur les stories les plus prioritaires en premier en équipe.
  Nous avons une story support / ticket avec un owner à la semaine pour traiter toutes les questions et/ou petites taches de support (max 1h) remontées par les équipes de production ou utilisateur.
• Standup à la place d’un autre. Après un tirage au sort, chacun réalise le standup d’un autre membre de l’équipe. Afin que l’ensemble des membres se tiennent informé de l’évolution et des blocages des autres membres. → NON.
• Prépare ton standup => OUI avec une amélioration du temps d’exécution du standup et de meilleurs éléments mis en avant.
• Le faire debout même à distance.
• Interrompre les discussions de deux personnes pour leur proposer de se réunir après le standup.
• Montré une vidéo faite par Persistent sur les standup https://www.youtube.com/watch?v=gtRIhs-AARM
• Nous avons essayé de garder les problématiques pour la fin du standup : elles sont évoquées par les personnes concernées, puis elles sont abordées à nouveau à la fin. Cela permet aux potentielles personnes non concernées de quitter le standup. Le PO s’exprime généralement en dernier car nous avons constaté que ce sont ses interventions qui généraient le plus de débats. Nous n’avons pas observé de réel gain de temps, mais cela permet une meilleure synthèse. Nous avons convenu que ces débats pourraient faire l’objet de petits ateliers hors du standup. Ils se font finalement de manière informelle dans la continuité du standup (n’excèdes jamais 10 minutes).
• Les batons et le pot d’argent, mais cela ne sert à rien du tout.
• Plutôt que dire qu’est ce qu’on a fait hier et ce qu’on va faire aujourd’hui, c’est rajouter “dans l’intérêt d’atteindre l’objectif du sprint”.
• Chaque fin de standup, on tire au sort le facilitateur pour le standup du lendemain. Le but étant d’essayer de concerner toute l’équipe. En début de standup, le facilitateur présente une funny picture… histoire d’introduire la cérémonie.
• Passer à un board à 2 colonnes (“Objectif du jour” et “Objectifs validés”), plus adapté à notre fonctionnement multi-projet (petite agence). Lorsqu’un ticket ne passe pas d’une colonne à l’autre, on essaie de comprendre pourquoi.
• Au début, le chef de projet participait au standup. Cela avait l’effet pervers que tout le monde lui parlait spécifiquement. Depuis le chef de projet ne s’exprime plus, mais participe à la réunion. Par contre, quelques mois après, nous retombons dans le travers, le standup est en quelque sorte un point sur l’avancement du projet réalisé au chef de projet.

Avez-vous des artefacts particuliers sur votre board pour améliorer votre standup ? Lesquels ?

• Non (réponse récurrente -> 16 fois)
• Pas de board mais un Jira (réponse récurrente -> 3 fois)
• Les trigrammes des participants, des blockers super visibles, 4 swimlines (urgences, demandes partenaires, dev fonctionnel et ops). On pointe la tâche ou US avant de commencer à parler.
• Des avatars pour chaque membre de l’équipe. Une section dédiée aux informations importantes.
• Projeté Pivotal et prévenir dans slack d’un retard. Si supérieur à 30 minutes, on n’attend plus le retardataire.
• Pas sur le board mais un baton de parole pour éviter les interruptions.
• Nous avons une colonne supplémentaire “ready to go to DONE” après WIP et avant DONE afin de déplacer pendant le standup toutes les tâches finies la veille. Nous mettons une tâche “DOD” (Definition of Done) à chaque story afin que quelqu’un fasse un check de tous les points définis dans la DOD de l’équipe (tests OK, démo prête, doc obligatoire remplie, etc.) quand celle-ci est considérée comme finie.
• Supprimer le standup journalier pour un check point hebdomadaire pour les managers ou les PO. Si c’est vraiment un outil pour les devs, dès le moment qu’on a une petite équipe, qui binôme, qui demande de l’aide quand elle a besoin d’aide (pas forcément à 10h le matin, mais n’importe quand) et traite les mises à jour des tableaux d’avancement (physique ou online) de manière rigoureuse, le daily ne sert à rien du tout. A mon avis, c’est là où il faut travailler, dans la création d’une équipe qui ait les bonnes pratiques tech et orga et un vrai esprit d’équipe. Le daily n’aide pas à ça, mais à saouler les devs plus qu’autre chose.

Il y avait également une question concernant les retards et comment les aborder. Visiblement la méthode Late=Cake est celle qui fonctionne le mieux. Il s’agit de tracer un gateau sur le board et de le découper en huit parts. A chaque fois qu’une personne est en retard, son nom est ajouté sur une part. Quand les huit parts du gateau sont consommées, la personne avec le plus de part apporte un gateau le lendemain / les cookies / les croissants.

Pour aller plus loin :

• les slides de la session « Comment obtenir des standup qui marchent » sont disponibles ici et abordent des points complémentaires pour avoir des daily au top.
• le site Visualisation Examples, évoqué plusieurs fois dans les slides, donne des exemples de management visuel
• Jason Yip, coach agile chez Spotify a publié un article très détaillé (et intéressant) sur le standup meeting. Il est régulièrement mis à jour.

J’en profite pour remercier tous les répondants (et retweeteurs, car vos réponses ont déjà aidé d’autres personnes. Après la conf, plusieurs personnes avait hâte de tester certaines de vos idées dès leur retour au bureau.

J’ai aussi particulièrement apprécié votre honnêteté dans vos réponses. Pour ne pas les dénaturer, je les ai restitué telles quelles (mais pas toutes, je vous rassure). J’ai aussi fait le choix de ne pas mettre les réponses ressemblantes.