Une alternative au Daily Scrum Meeting

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.

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.

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.

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.

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.

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.

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

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.

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

Etape 3 : Parcourir

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

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 ! 🙂