Daily Standup — définition, règles de la réunion quotidienne et bénéfices

Qu'est-ce que le Daily Standup ?

Daily Standup — une courte réunion de l'équipe Scrum qui a lieu au même endroit et à la même heure chaque jour ouvré. Timebox — 15 minutes. Il est connu sous différents noms : Daily Scrum (dans le Guide Scrum), synchronisation matinale, morning circle, daily. L'objectif est de synchroniser l'équipe, d'identifier les bloqueurs et d'ajuster les plans de la journée. Le daily n'est pas un rapport pour le manager, mais un outil d'auto-organisation de l'équipe. L'équipe décide comment structurer la réunion, pas le manager.

L'origine du terme « standup » vient de la pratique littérale de se tenir debout pendant la réunion : les participants se rassemblent autour du tableau et ne s'assoient pas. Cela crée un sentiment de temporalité — personne ne veut rester debout plus de 15 minutes. Le standup physique est encore utilisé par 60% des équipes (selon Scrum.org 2025), les autres sont passés au format远程 via Zoom, Slack Huddle ou Teams. En format远程, il est important de maintenir la discipline : caméras allumées, pas de multitâche, préparation préalable des réponses.

Le Guide Scrum 2025 définit le Daily Scrum comme un événement pour les Developers (développeurs). Le Product Owner et le Scrum Master peuvent y assister mais ce n'est pas obligatoire. Si le PO ou le SM assistent, ils ne dirigent pas la réunion. L'équipe choisit sa propre structure : les trois questions classiques ou un board walk. Point clé : le daily sert à inspecter la progression vers le Sprint Goal, pas le statut de chaque tâche. Si la réunion se transforme en énumération des tâches du tableau, l'équipe a perdu le focus sur le Sprint Goal.

Les trois questions du Daily Standup

Question 1 : « Qu'ai-je fait hier pour atteindre le Sprint Goal ? » — un bref résumé des tâches accomplies. Pas « j'ai travaillé sur APP-123 », mais « terminé l'écran de connexion, PR envoyé en review ». La formulation « pour atteindre le Sprint Goal » est intentionnelle : elle relie le travail quotidien à l'objectif général du sprint. Si un développeur ne voit pas le lien entre sa tâche et le Sprint Goal, c'est un signal que la tâche n'est peut-être pas nécessaire dans le sprint actuel. Dans le développement mobile, les résultats d'hier incluent non seulement le code mais aussi les tests, la documentation et la configuration CI/CD.

Question 2 : « Que prévois-je de faire aujourd'hui pour atteindre le Sprint Goal ? » — le plan pour la journée en cours. Pas plus de 2-3 éléments. Un développeur pourrait dire : « Aujourd'hui, je vais terminer la ViewModel pour l'écran de profil, écrire des tests unitaires et lancer un build sur un appareil réel. » Si le plan correspond à celui d'« hier », c'est un signal que la tâche est trop grande et doit être décomposée. La règle des deux jours : si une tâche n'est pas terminée en 2 jours de travail, elle doit être divisée en sous-tâches, sinon elle stagnera dans In Progress pendant des semaines.

Question 3 : « Quels bloqueurs entravent ma progression ? » — la question la plus importante. Un bloqueur est quelque chose que le développeur ne peut pas résoudre seul : attendre une review (si le SLA de review est dépassé), un émulateur qui ne fonctionne pas, une API non prête, besoin d'accès au dépôt. Important : les bloqueurs doivent être nommés mais pas résolus pendant le daily. Après la réunion, le développeur et le Scrum Master / manager organisent la résolution du bloqueur. Selon Scrum.org (2025), 70% des bloqueurs des équipes mobiles sont liés à : l'attente de reviews (30%), l'indisponibilité des appareils de test (20%) et les dépendances du backend (20%).

Comment mener un standup correctement

Heure et lieu. Le daily a lieu à la même heure chaque jour — généralement au début de la journée de travail (9h00-10h00). Pour les équipes distribuées, on choisit une heure confortable pour tous les fuseaux horaires. Durée — strictement 15 minutes. Un minuteur est obligatoire. Si l'équipe ne termine pas à l'heure, le problème ne vient pas du daily mais du processus : soit trop de participants, soit les tâches sont discutées au lieu d'être simplement nommées. La règle du ping-pong : chaque participant parle pendant au maximum 60 secondes. Après avoir répondu, il passe la parole au suivant.

Format Board Walk. Une alternative aux trois questions : l'équipe déplace à tour de rôle les tâches sur le tableau Scrum en commentant les changements. Un développeur prend sa tâche de To Do, la déplace vers In Progress et dit : « Je prends APP-123 — l'écran de commande, j'ajoute le champ de code promo. » Le Board Walk offre une compréhension visuelle de la progression et révèle les tâches « oubliées » — celles qui n'ont pas bougé depuis 3+ jours. Board Walk est préférable pour les équipes distribuées utilisant Jira/Linear — tout le monde voit le tableau au lieu d'écouter un monologue.

Pour les équipes distantes : les caméras doivent être allumées — selon Microsoft Research (2025), avoir la caméra allumée augmente l'engagement de 40%. Utilisez un écran partagé avec le tableau des tâches (Jira, Linear, Miro). Écrivez les bloqueurs dans le chat — cela crée une trace écrite. Encouragez les emojis de réaction (sauf instruction de l'utilisateur — les emojis ne sont pas utilisés) — un pouce levé sur le message d'un collègue. Après le daily, prenez 2-3 minutes pour le parking lot : les sujets nécessitant une discussion séparée sont notés dans une liste de réunions de suivi. Compétence clé du Scrum Master : arrêter la discussion pendant le daily et la déplacer vers le parking lot.

Erreurs typiques dans les réunions

Erreur 1 : rapport de statut pour le manager. Les développeurs lisent à tour de rôle ce qui est écrit dans Jira, le manager pose des questions de clarification, la réunion dure 45 minutes. Solution : rappeler que le daily est pour l'équipe, pas pour le manager. Le manager peut consulter le statut sur le tableau. Si le manager pose des questions, déplacez-les vers des réunions 1:1. Une équipe qui transforme le daily en rapport de statut perd 2-3 heures par semaine sur tous les participants. Avec 8 développeurs, cela représente 16-24 heures-personne par mois — la perte d'un sprint complet sur un an.

Erreur 2 : résoudre les problèmes sur place. Un développeur dit « J'ai un bug avec gRPC — le projet ne compile pas » et toute l'équipe passe 20 minutes à discuter des solutions. Solution : enregistrer le bloqueur dans le parking lot et continuer le daily. Après la réunion, rassembler les personnes concernées (le développeur + ceux qui peuvent aider) pour une discussion de 10 minutes. Selon Basecamp (Shape Up), seulement 20% des problèmes découverts pendant le daily nécessitent une discussion de toute l'équipe. Le reste est résolu par deux développeurs en 10 minutes.

Erreur 3 : retards et absences. Quelqu'un arrive 5 minutes après le début et il faut tout répéter. Solution : établir la règle que « le daily commence à l'heure, les retardataires n'entrent pas » ou « le retardataire paie une amende » (café pour l'équipe). Encore plus strict : le daily a lieu à une heure fixe ; si quelqu'un est systématiquement en retard, c'est un problème de discipline traité en 1:1. Le daily est la synchronisation de la journée. Si un développeur le manque, il n'est pas synchronisé et risque de faire le mauvais travail pour l'équipe.

Erreur 4 : trop de participants. Une équipe de 15+ personnes, chacun parlant une minute — 20+ minutes au total. Solution : diviser l'équipe en sous-groupes par fonctionnalité/module. Chaque sous-groupe tient son propre daily (5-7 personnes). Un représentant de chaque sous-groupe peut assister à un standup inter-équipes (si une synchronisation entre équipes est nécessaire). Alternative : un standup asynchrone via Slack/GeekBot où chacun écrit ce qu'il a fait / prévoit / les bloqueurs.

Standup asynchrone : alternatives

Standup asynchrone — un format où les participants écrivent leurs réponses dans un chat (Slack, Telegram, Teams) ou via un bot spécialisé (GeekBot, Standuply, Status Hero) au lieu d'une réunion orale. Adapté aux équipes distribuées avec un décalage horaire de 3+ heures. Chaque participant répond aux mêmes trois questions avant une certaine heure (par exemple, avant 11h00). Le bot collecte les réponses et publie un résumé dans le canal commun. Avantages : flexibilité, trace écrite, pas de problème de retard.

Inconvénients du format asynchrone : pas d'interaction en direct — les signaux non verbaux sont perdus, les bloqueurs sont plus difficiles à identifier (un développeur peut ne pas écrire sur un problème). Un bloqueur écrit dans un chat peut passer inaperçu jusqu'à la fin de la journée. Selon GitLab (2025), 40% des équipes qui sont passées au standup asynchrone sont revenues à l'oral en 3 mois. Recommandation : utilisez un hybride — 3 jours de standup oral (lun, mer, ven) et 2 jours asynchrone (mar, jeu). Ou : standup oral 1-2 fois par semaine, asynchrone les jours restants.

Outils pour le standup asynchrone : GeekBot (Slack) — pose les trois questions et publie un résumé ; Standuply — s'intègre à Jira et offre un suivi automatique ; Status Hero — collecte les statuts et génère des rapports hebdomadaires pour la direction. Le choix de l'outil dépend de la culture de l'équipe : dans les startups, un bot Slack suffit ; dans les environnements d'entreprise, Standuply avec intégration aux processus d'entreprise peut être nécessaire. Règle importante : quel que soit le format, les réponses doivent être visibles par toute l'équipe, pas seulement par le manager. La transparence est une valeur fondamentale d'Agile.

Spécificités du daily pour les équipes mobiles

Une équipe mobile fait face à des bloqueurs spécifiques pendant le daily. Principaux : build du projet en CI (le build Gradle peut prendre 20+ minutes — s'il casse, le développeur perd une heure à déboguer), attente de TestFlight / Firebase App Distribution (publier un build pour les testeurs prend 30-60 minutes), problèmes avec les émulateurs et simulateurs (Android Emulator nécessite KVM/HAXM, iOS Simulator uniquement sur Mac). Le daily d'une équipe mobile doit inclure une vérification rapide de l'état du build : « Le build passe-t-il ? Tous les tests sont-ils verts ? »

Pour les projets multiplateformes (Flutter, React Native), le daily peut inclure une question sur l'état du code partagé. Si deux développeurs modifient simultanément le même fichier Dart et que l'un fusionne ses modifications, le second sera confronté à des conflits. Conseil : utilisez le Board Walk avec un tableau segmenté par plateforme (Android / iOS / Shared). Cela aide à visualiser qui travaille où et si les modifications se chevauchent. Pour les projets Flutter, utilisez un tableau avec des colonnes pour Platform Channel, BLoC/Cubit, UI et Tests.

Préparation à la release est un autre point spécifique au développement mobile dans le daily. 3 à 5 jours avant la release, ajoutez la question : « Le build est-il prêt pour la release ? Toutes les métadonnées (icônes, captures d'écran, descriptions) sont-elles à jour ? » Cela évite les situations où les développeurs finissent de coder le jour de la release alors que le build et la publication prennent encore 3 à 4 heures. Tracker de release — un tableau séparé avec une checklist : mettre à jour versionCode/versionName, vérifier ProGuard, signer l'AAB, télécharger dans la console développeur, rédiger les notes de version.