Le Daily Scrum n’est pas fait pour suivre les développeurs

Arrêtons avec les questions 👇
🚫 Qu’est-ce que j’ai fait hier ?
🚫 Qu’est-ce que je compte faire aujourd’hui ?
🚫 Quels sont les problèmes que j’ai rencontrés ?

⚠️ Cela n’est qu’un exemple (incomplet) issu du Scrum Guide qui a d’ailleurs été supprimé dans sa version 2020.

Ces questions ont tendance à :
👉 tendre vers une justification de ce qu’on a fait la veille
👉 rallonger le temps du meeting avec tout le monde qui doit parler
👉 diriger le daily scrum vers un simple reporting adressé à une personne tiers
👉 mettre en avant le travail d’individus au lieu de celui de l’équipe dans sa globalité
👉 perdre de l’intérêt pour les développeurs
👉 accentuer la comparaison et générer du stress à ceux qui ont le sentiment d’avoir moins « travailler »
👉 cacher les véritables éléments utiles afin de permettre aux membres de l’équipe d’avancer

Comment faire alors ?

✅ Être focus sur les fonctionnalités en cours de développement plutôt que sur les personnes qui les développent
✅ S’attarder sur des blocages toujours présents plutôt que des problèmes qui ne sont plus d’actualités
✅ Demander de l’aide, des informations manquantes ou alerter l’équipe d’impacts éventuels
✅ Partager des pistes d’améliorations
✅ Poser des questions ouvertes sans imposer un tour de table
✅ Favoriser l’effort collectif plutôt qu’individuel

Le daily est fait pour les développeurs par les développeurs !

Et si le guide est assez vague sur la manière dont le Daily Scrum doit être conduit, rien ne nous empêche d’aller chercher des bonnes pratiques ailleurs comme le Daily Kanban meeting.

Ce dernier se focalise plus sur les tâches à réaliser que sur les personnes qui les réalisent !

---