Photo by Christian Stahl on Unsplash
Le Daily Scrum Meeting est pour moi une des pratiques Agile les plus controversées. En effet, étant à la fois un des éléments les plus plébiscités par les équipes, il est également celui qui peut leur créer le plus de frustration.
La raison est assez simple : son intention n’est pas toujours claire, ce qui engendre facilement une dérive dans son utilisation.
Je vous propose ici de décrire une alternative au Daily Scrum Meeting comme on peut le connaître habituellement, en espérant que cela vous ouvrira le champ d’options quant à votre utilisation actuelle.
Bonne lecture !
Pourquoi changer ?
Lorsque je rencontre une nouvelle équipe, il est assez rare qu’elle n’ait pas entendu parlé du Daily Scrum Meeting.
C’est alors une bonne opportunité pour moi de demander comment cela se passe afin de partir de leur propre expérience du sujet.
Voici les patterns que je retrouve souvent :
1. Un protocole incomplet
Lorsque je demande comment l’équipe conduit son DSM, elle m’explique souvent que chaque membre répond tour à tour à ces 3 questions :
- Qu’est-ce que j’ai fait hier ?
- Qu’est-ce que je vais faire aujourd’hui ?
- Quels sont les problèmes que je rencontre ?
Malheureusement, ce protocole est incomplet et est une simplification maladroite du protocole exemple décrit dans le Scrum Guide.
Scrum Guide (Nov 2017)
Le protocole décrit est le suivant :
|
2. Une réunion de reporting
En effet, les questions formulées comme précédemment sont auto-centrées :
- Qu’est-ce que j’ai (moi) fait hier ?
- Qu’est-ce que (moi) je vais faire aujourd’hui ?
- Quels sont les problèmes que (moi) je rencontre ?
Cela a tendance à transformer le DSM en réunion de reporting où chacun raconte sa propre histoire plutôt que de prendre part à une histoire commune vécue ensemble.
Note : j’entends même parfois que cela provoque un certain stress pour les participants qui peuvent se sentir forcés d’avoir quelque chose à raconter. Chacun réfléchit alors à ce qu’il va dire dans son coin plutôt que d’être à l’écoute des autres – on risque alors de noyer la véritable information importante à remonter à l’équipe.
Scrum Guide (Nov 2017)
En reprenant la formulation officielle du protocole exemple, 2 notions supplémentaires sont mises en avant :
|
Il est important de souligner que la réunion de reporting est de plus une dérive de l’intention initiale du DSM.
J’aime d’ailleurs préciser à cet effet que :
Le reporting a généralement plus de valeur
pour la personne qui le reçoit que pour la personne qui le réalise.
Scrum Guide (Nov 2017)
« La Mêlée Quotidienne est un événement […] pour l’équipe de développement. » Le DSM est donc un événement qui doit avoir de la valeur pour l’équipe de développement avant tout. Cela ne peut donc être en aucun cas une réunion de reporting à des instances autres. « L’équipe de développement y planifie ses activités pour les prochaines 24 heures. » L’intention initiale du DSM est bien de promouvoir l’inspection et l’adaptation de l’équipe de développement – auto-organisée – en vue d’atteindre son objectif de sprint. « Elle met en lumière et promeut les décisions rapides. C’est une réunion clé d’inspection et d’adaptation. » C’est une réunion de synchronisation et de prise de décision collective avant tout. L’important étant de se mettre d’accord sur ce qui est le plus pertinent de réaliser ensemble aujourd’hui pour augmenter ses chances de ne pas louper la cible. |
3. Un positionnement en cercle fermé
Une manière de renforcer l’effet de la réunion de reporting : se placer en cercle et se regarder dans le blanc des yeux !
Pourquoi est-ce un problème ?
Si l’on regarde dans le domaine du sport (football, basketball, rugby…), l’objectif de ces regroupements est avant tout de redonner un élan vers l’avant plutôt que de regarder en arrière. L’information y est donc simple pour que la stratégie soit facile à comprendre dans le temps imparti et la mise en oeuvre la plus fluide possible.
Dans le cadre de projets complexes comme dans le développement logiciel par exemple, même si l’on peut être attentif sur les 2 ou 3 premières personnes qui parlent, il reste néanmoins difficile de garder en tête toutes les informations qui seront partagées par les potentielles 8 autres personnes de l’équipe, tout en gardant en vue l’objectif à atteindre. De ce que j’ai pu voir dans mes interventions, la plupart du temps lorsque les participants sont en cercle, ils sont plutôt en phase d’attente de leur tour de parole plutôt qu’en écoute active de l’ensemble du groupe.
On souligne ainsi à nouveau la dimension individuelle du travail : chacun parle tour à tour pour dire ce qu’il a fait sans pour autant avoir une vision globale du travail à fournir et la manière dont chacun contribue à cet ensemble.
Il est important que l’ensemble de l’équipe soit alignée sur la situation actuelle : c’est pourquoi on utilise le Management Visuel. Ce n’est pas pour rien que son motto principal est : « Voir Ensemble – Agir Ensemble – Apprendre Ensemble » Scrum Guide (Nov 2017) « Chaque jour, les membres de l’Équipe de Développement sont amenés à comprendre la façon dont ils ont l’intention de travailler ensemble en tant qu’équipe auto-organisée pour atteindre l’Objectif du Sprint. » L’apport du support visuel est une manière simple et pratique de matérialiser la situation actuelle et d’aider l’équipe à prendre de meilleures décisions ensemble. De ce fait, elle continue à apprendre de son fonctionnement et peut plus facilement focaliser ses efforts d’amélioration en se basant sur une même vision globale de leur histoire commune. Le placement devrait alors plutôt ressembler à un arc de cercle devant le Management Visuel. |
4. Une réunion qui dure
On entend parfois que des DSM durent 1h chaque jour (généralement pour les raisons citées plus tôt). Il arrive souvent que les problèmes soient discutés pendant le DSM ce qui engendre un nombre de discussions supplémentaires ne concernant pas l’ensemble des participants de l’équipe.
Il est important de garder en tête que tous les événements Scrum sont timeboxés pour une raison : apprendre par la frustration pour faire mieux la prochaine fois. Ne pas respecter ces timeboxes, c’est simplement s’empêcher d’apprendre et de s’améliorer.
Scrum Guide (Nov 2017)
« La Mêlée Quotidienne est un événement à durée fixe (time-box) de 15 minutes pour l’Équipe de Développement. » |
Une raison pour que la réunion dure est également le nombre de personnes. Il arrive souvent le nombre de personnes recommandé dans une équipe de développement soit dépassé ce qui implique naturellement un allongement du temps si l’on garde le protocole initial où tout le monde doit absolument parler.
Scrum Guide (Nov 2017)
« La taille optimale de l’Équipe de Développement doit être suffisamment petite pour rester réactive et suffisamment grande pour réaliser un travail significatif pendant un Sprint. En-dessous de 3, les membres de l’Équipe de Développement perdent en interaction et cela génère de faibles gains de productivité. […] Avoir plus de neuf membres demande trop de coordination. » |
Il était donc temps de faire autrement, c’est ce que je vous propose dans la suite de cet article ! 😉
Une alternative : le Daily Kanban
Vous me direz qu’encore une fois c’est une comparaison Scrum VS Kanban que je fais ici. Eh bien oui, mais non.
- Oui, car c’est effectivement le protocole du Daily Kanban Meeting que je vais vous décrire avec les avantages que j’y trouve pour répondre aux dérives habituelles du DSM.
- Non, car le débat Scrum VS Kanban n’a pour moi aucun sens. Plutôt que de séparer, je préfère aujourd’hui intégrer le meilleur des deux.
Et comme je le disais dans mon article sur une variante du ROTI :
Ce n’est pas l’outil ou la méthode qui importe,
mais la manière dont on l’utilise et ce que cela peut nous apporter.
Voici donc le protocole que je propose aujourd’hui aux équipes que j’accompagne.
Protocole de Daily
Conditions initiales :
- Positionnement de l’équipe en arc de cercle devant son Management Visuel
- Timebox fixée à 15 minutes
- Une personne est à la facilitation
Etape 1 : Aligner sur la situation actuelle
Est-ce que le tableau est à jour ? |
L’objet ici est de s’assurer que l’on voit bien la situation actuelle : si les tâches n’ont pas été déplacées avant le Daily, c’est le bon moment pour le faire. On a donc ici l’information de ce sur quoi les personnes ont travaillé la veille, ce qui normalement ne nécessite pas d’être évoqué à nouveau.
On passe ensuite à l’étape 2.
Notes :
|
Etape 2 : Alerter
Y a t-il des points d’attention à remonter à l’équipe ? (Informations importantes, bloquants, urgences…) |
- Des urgences qui viennent de tomber
- Des blocages qui durent depuis longtemps
- Des entrants à venir qui méritent l’attention de l’équipe
Demander ensuite si l’ensemble des personnes sait ce qui est le plus important à réaliser aujourd’hui et comment ils vont y contribuer :
- si oui (tout le monde sait quoi faire aujourd’hui), clôturer le Daily
- si non (tout le monde ne sait pas encore quoi faire exactement aujourd’hui), on passe à la 3ème étape
Notes :
|
Etape 3 : Parcourir
[Parcourir le tableau de la droite vers la gauche] |
Si l’on a dépassé l’étape précédente, on va « Walk the board » comme diraient nos amis anglo-saxons en parcourant les éléments du tableau, et cela de la droite vers la gauche.
Pourquoi de la droite vers la gauche ?
Habituellement, les tableaux de Management Visuel décrivent un processus qui va de la gauche vers la droite.
(Je le précise car en jouant l’atelier « Au Tableau« , j’ai déjà eu des cas où le processus allait de la droite vers la gauche voire de haut en bas ou en spirale ! :-D)
« Stop Starting, Start Finishing »
En parcourant le tableau de la fin vers le début, on se penche sur les éléments qui sont les plus proches de la sortie afin d’augmenter les chances de les terminer.
Ce qui peut être discuté sur les éléments abordés :
- Etat d’avancement du moment
- Informations importantes à partager à l’équipe à ce sujet
- Problématiques rencontrées
- Demande d’aide pour achever l’élément
Comme pour le DSM, l’idée n’est pas de rentrer dans les détails mais de transmettre des informations ou d’expliciter un problème (pas de le résoudre). En effet, la recherche de solutions se fait immédiatement après le DSM avec les personnes impliquées ou concernées.
Plus on devient mature dans l’utilisation du Daily Kanban, plus on ne parle que des problématiques rencontrées pour synchroniser l’équipe et passer à l’action.
A chaque déplacement de colonnes, on demande si tout le monde sait ce qui est le plus important à réaliser aujourd’hui et comment chacun va y contribuer.
- Si oui (tout le monde sait quoi faire aujourd’hui), on clôture le Daily
- Si non (tout le monde ne sait pas encore quoi faire exactement aujourd’hui), on continue à parcourir le tableau
Notes :
|
Conclusion
Depuis que j’ai découvert le Daily Kanban Meeting, difficile pour moi de revenir en arrière.
En effet, il répond de manière naturelle à différentes problématiques :
- Le protocole est simple à suivre et se base sur la transparence pour une meilleure prise de décision collective
- L’orientation flux focalise naturellement l’attention sur l’objectif du collectif plutôt que sur les objectifs individuels
- La facilitation par une personne donne du dynamisme à la réunion. De plus, vu que l’on se focalise sur le travail et non pas sur les personnes, on diminue la sensation de reporting ou de flicage de chacun.
- Le timing est plus facilement respecté pour de grands groupes : une équipe de 20 personnes peut aisément tenir les 15 minutes lorsqu’elle est habituée au protocole 😉
Bref, je vous invite à l’expérimenter et à m’en donner des nouvelles car l’essayer c’est l’adopter ! 🙂
4 réflexions sur “Une alternative au Daily Scrum Meeting”
Bonjour Olivier,
Martin Fowler avait fait un article sur différents patterns possibles, Cf. https://www.martinfowler.com/articles/itsNotJustStandingUp.html
Dans le Scrum Guide 2017, il est écrit que les 3 questions « classiques » ne sont qu’un exemple de pattern utilisable.
Dans le Kanban Guide for Scrum Team 2018, il est proposé de faire un « Flow based Daily Scrum » proche de ce que tu proposes.
Cordialement
Olivier
Bonjour Olivier,
Merci pour l’information ! 🙂
Bien cordialement,
Olivier
Ping : Agilité@Scale
Merci, j’apprécie particulièrement la précision avec laquelle tu décris le protocole du daily kanban.
En parlant de process dans différents orientations, j’ai moi-même expérimenté de retourner mon personal kanban. J’y ai vu des effets immédiats et insoupçonnés! Ça met naturellement plus de focus sur ‘start finishing, stop starting’ (plus de détails ici https://philippe.bourgau.net/its-time-to-flip-your-kanban-board-setup/) Au point où je me demande si on ne devrais pas plus souvent réorienter nos tableaux ?
Merci pour ce poste je vais essayer de faire essayer ça à mon équipe.