Reprenez possession du Scrum quotidien : une liste pour qu'il cesse d'être un rapport d'avancement
Observez un Scrum quotidien en difficulté et vous entendrez le même rituel : chacun rapporte hier, aujourd'hui et ses obstacles, les yeux rivés sur la personne qui semble diriger. Cela paraît productif et c'est presque inutile. Le Guide Scrum est clair : le Scrum quotidien est un événement des développeurs, par les développeurs, pour inspecter l'avancement vers l'objectif de sprint et adapter leur plan pour la prochaine journée de travail. Ce n'est pas une réunion de suivi, et dès qu'il en devient une, vous avez troqué une séance de planification contre une représentation.
Cette dérive s'est aggravée lorsque les équipes sont passées en télétravail en 2020 et 2021. En visioconférence, le réflexe naturel est de parler à tour de rôle en s'adressant à l'écran, ce qui transforme discrètement l'événement en reddition de comptes vers le haut plutôt qu'en planification entre pairs. Le remède n'est pas un nouvel outil; c'est de changer la raison d'être de ces quinze minutes. Utilisez cette liste cette semaine.
Posez un diagnostic honnête
Les gens s'adressent-ils au Scrum Master ou à un gestionnaire plutôt qu'entre eux?
La réunion pourrait-elle être remplacée par la lecture d'un compte rendu écrit sans rien perdre?
L'objectif de sprint n'est-il jamais mentionné du début à la fin?
Le groupe se sépare-t-il sans aucun changement à qui fait quoi aujourd'hui?
Dépasse-t-elle régulièrement les quinze minutes parce qu'on règle les problèmes sur place?
Un « oui » à la plupart de ces questions signifie que vous avez une réunion de suivi déguisée en Scrum.
Menez-le plutôt comme une séance de planification
Partez de l'objectif de sprint, pas des personnes. Commencez par lire l'objectif de sprint à voix haute et regardez le tableau à la lumière de cet objectif. La question n'est pas « qu'avez-vous fait » mais « sommes-nous toujours en voie d'atteindre cet objectif, et sinon, que changeons-nous aujourd'hui? »
Laissez les développeurs le diriger. Le Scrum Master peut accompagner, mais la responsabilité revient aux développeurs. Si vous êtes Scrum Master, essayez de vous taire ou de vous éclipser quelques jours; un Scrum quotidien qui s'effondre sans vous ne leur a jamais appartenu.
Mettez les analyses approfondies de côté. Lorsqu'un vrai problème surgit, nommez-le, notez qui s'en chargera et poursuivez. Le dépannage détaillé se fait juste après, avec uniquement les personnes concernées.
Produisez un plan, pas un procès-verbal. L'événement doit se terminer par un plan concret pour la journée — travail réordonné, binôme organisé, dépendance relancée — et non par un simple compte rendu bien rangé de déclarations.
Rendez les obstacles visibles et attribués. Un obstacle soulevé sans responsable nommé ni prochaine étape n'est qu'une annonce. Consignez-le là où l'équipe le verra et agira dessus.
Les gestionnaires qui ont réellement besoin de visibilité peuvent l'obtenir par le tableau, le burndown ou une brève discussion avec le Scrum Master — rien de tout cela n'exige de détourner l'événement de planification de l'équipe. Protéger cette distinction est l'une des actions les plus rentables d'un Scrum Master, car une équipe qui planifie sa propre journée est maître de son propre résultat.
Si vos événements agiles se sont figés en rituels de reddition de comptes et que vous voulez de l'aide pour en refaire de véritables séances de travail, le conseil en réalisation de programmes et de projets de XNM accompagne les équipes pour que leurs cadences méritent leur place à l'agenda.