Le mot « réunion » évoque parfois une salle pleine de personnes discutant de sujets sérieux : certaines s’ennuient, d’autres peinent à suivre et d’autres cherchent agressivement à imposer leur point de vue. Les échéances, le temps limité, la concurrence et le besoin de rester en tête exigent une coordination plus ciblée. Dans Scrum, le Daily Scrum offre cette possibilité aux Developers.
Le regard de l’International Scrum Institute™
10 conseils pour tirer le meilleur de vos Daily Scrums
Que sont les réunions Scrum ?
Le Daily Scrum est un événement court et ciblé destiné aux Developers de la Scrum Team. Chaque jour ouvré du Sprint, à la même heure et au même endroit, ils inspectent les progrès vers l’objectif de Sprint et adaptent le plan du lendemain. Certaines équipes se réunissent debout le matin pour rester brèves ; ces choix sont facultatifs, pas des règles Scrum. Les trois questions suivantes constituent une structure courante, mais les Developers peuvent choisir un autre format servant le même objectif :
- Qu’a-t-on fait hier ?
- Que faut-il faire aujourd’hui ?
- Y a-t-il des obstacles ?
Ces réunions peuvent devenir trop longues ou perdre leur but. Voici des conseils pratiques pour réussir le Daily Scrum. Considérez ces techniques comme des options, pas comme des exigences Scrum supplémentaires :
1. Respectez la règle : le temps, c’est de l’argent…
Commencez chaque jour ouvré à l’heure convenue, même si quelqu’un est en retard. Certaines équipes envisagent des incitations à la ponctualité ou des sanctions : ces pratiques facultatives ne sont pas des règles Scrum et doivent être discutées ouvertement, pas imposées. Restez bref et précis. Le Daily Scrum a une durée maximale de 15 minutes.
2. Définissez à l’avance les règles de la réunion :
L’ordre et le respect des tours de parole favorisent une discussion ciblée. Le Daily Scrum appartient aux Developers, qui planifient ensemble plutôt que de rendre compte à un « chef Scrum ». Si le Product Owner ou le Scrum Master travaille activement sur des éléments du Sprint Backlog, il participe comme Developer. Laissez chacun parler sans interruption.
3. Gardez le cap :
Préparez les sujets et priorités importants pour avancer vers l’objectif de Sprint. Le travail en cours et les échéances proches constituent des points de départ utiles. Centrez les échanges sur le plan commun des Developers ; réservez les autres sujets à une autre discussion.
4. Maintenez l’intérêt avec une touche de plaisir :
La réunion étant courte, chacun doit rester impliqué. Une plaisanterie, une citation motivante, une bande dessinée ou une image intéressante peut rapprocher l’équipe si cela n’empiète pas sur la durée prévue. Tirer au sort le prochain intervenant peut aussi donner à chacun une chance équitable de contribuer. Ces techniques sont facultatives ; utilisez-les uniquement si elles aident l’équipe.
5. Ni ordinateur portable ni téléphone, s’il vous plaît… Une zone sans technologie…
Il est difficile de se concentrer quand certains lisent leurs messages, répondent aux courriels, jouent ou parcourent du code. Une règle convenue de limitation des appareils peut éviter les distractions et témoigner du respect. Gardez toutefois la technologie nécessaire à la participation à distance et à l’accessibilité : le but est l’attention, pas l’interdiction générale d’outils utiles.
6. Envisagez de rester debout si cela convient à tous…
Certaines équipes parlent de réunion debout, car cela peut favoriser brièveté, concentration et énergie. Une réunion classique confortablement assise peut plus facilement s’éterniser, mais rester debout n’est pas une exigence Scrum. Choisissez un format adapté à tous, y compris aux collègues qui doivent s’asseoir.
7. Donnez l’alerte si la réunion perd son sens…
Si elle devient un rituel improductif de compte rendu, prenez le problème au sérieux. La sauter peut montrer de manière spectaculaire que votre temps serait mieux consacré au développement, mais le Daily Scrum reste un événement Scrum obligatoire. Parlez-en à l’équipe et au Scrum Master, puis rétablissez une discussion utile sur l’objectif de Sprint et le plan du lendemain.
8. Utilisez un « parking » pour les sujets non résolus
Le Daily Scrum aide les Developers à inspecter la progression, coordonner la suite et repérer les obstacles. La résolution détaillée des problèmes peut suivre avec les personnes concernées. Gardez un « parking » des sujets demandant plus de temps, sur un carnet ou tableau si utile. Rendez-le accessible en dehors du Daily Scrum pour ajouter des thèmes sans détourner l’attention pendant l’événement. Organisez ensuite les échanges nécessaires avec les bonnes personnes.
9. Préparez-vous à l’avance
Le temps étant limité, préparez les progrès, prochaines étapes et difficultés concernant l’objectif de Sprint. Le travail d’hier, le plan d’aujourd’hui et les obstacles peuvent structurer l’échange, sans constituer un script obligatoire. Les Developers conviennent du format ciblé ; le Scrum Master aide à en comprendre le but plutôt que de choisir les comptes rendus à entendre. Reportez les sujets hors propos à un suivi adapté.
10. Utilisez les réunions Scrum pour insuffler l’esprit d’équipe
Incluez les collègues à distance, y compris ceux travaillant en sous-traitance. La vidéo ou l’audioconférence facilite la coordination. Choisissez une heure raisonnable pour tous, plutôt que 1:00 du matin pour les collègues distants. Encouragez les échanges entre membres plutôt que tous les commentaires adressés au Scrum Master. Lorsque c’est possible, le contact visuel aide à créer ce lien. Le but est une collaboration efficace et une compréhension partagée.
Le mot de la fin !
Vous connaissez peut-être les points quotidiens, appels du matin, réunions matinales ou réunions debout. Le Daily Scrum a un but précis : inspecter la progression vers l’objectif de Sprint et adapter le plan des Developers. Échanger sur les réalisations d’hier et le travail prévu aujourd’hui clarifie ce qui est terminé et ce qui reste. Cela favorise aussi la responsabilité mutuelle : lorsqu’une personne dit « Je ferai cette tâche aujourd’hui », l’équipe peut inspecter le résultat et s’adapter le lendemain, sans transformer l’événement en compte rendu à un manager.
