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.

Scrum Guide (Nov 2017)

Le protocole décrit est le suivant :

  • Qu’ai-je fait hier qui a aidé l’équipe de développement  à atteindre l’objectif de sprint ?
  • Que vais-je faire aujourd’hui pour aider l’équipe de développement à atteindre l’objectif de sprint ?
  • Est-ce que je vois des impediments (obstacles, boulets) qui nous empêcheraient (moi ou l’équipe de développement) d’atteindre l’objectif de sprint ?

2. Une réunion de reporting

Photo by Olu Eletu on Unsplash

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 :

  • La dimension équipe du travail : ce que l’on fait est destiné à aider l’effort collectif (et non pas la somme des efforts individuels) à atteindre son objectif. On en revient à la notion de responsabilité globale et partagée plutôt que locale et spécialisée.
  • L’objectif du sprint : on ne fait pas que dépiler des tâches, bien au contraire. On sélectionne les bonnes permettant de construire l’incrément de produit et atteindre l’objectif fonctionnel que l’on s’est fixé en tant qu’équipe auto-organisée.

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

Photo by NeONBRAND on Unsplash

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

Photo by Josh Calabrese on Unsplash

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 :

  • C’est une étape dont on ne soupçonne pas toujours l’intérêt.
  • En effet, lorsque l’on pose la question, on voit souvent un hochement de tête des personnes disant « oui oui c’est bon » jusqu’à ce qu’on se rende compte plus tard que ce n’était pas le cas !
  • On verra dans les étapes suivantes l’impact de cette première phase 😉

Etape 2 : Alerter

Photo by Hello I’m Nik on Unsplash

Y a t-il des points d’attention à remonter à l’équipe ?

(Informations importantes, bloquants, urgences…)

  
C’est le moment propice pour aller droit à l’essentiel sur le tableau s’il y a lieu d’être :
  • Des urgences qui viennent de tomber
  • Des blocages qui durent depuis longtemps
  • Des entrants à venir qui méritent l’attention de l’équipe
On peut également partager des informations générales importantes pouvant avoir un impact sur l’ensemble 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 :

  • Un des intérêts ici est de ne pas avoir à parcourir des éléments qui de toute manière ne seront pas traités dans la journée car les points d’attention vont déjà prendre toute la journée. Au pire des cas, le prochain Daily arrive dans… 24 h ! 🙂
  • On garde de plus bien la focalisation de l’équipe sur un objectif à atteindre dans la journée pour garder la notion d’inspection est d’adaptation propre au DSM.

Etape 3 : Parcourir

Photo by Nick Fewings on Unsplash

[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)

L’important est surtout de le parcourir de la fin vers le début afin de répondre à mon motto préféré :
« 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 :

  • Une discussion peut également émerger pour définir ce qui devrait être « tiré » par la suite si l’on termine des éléments avant la fin de la journée
  • On peut voir ici l’impact de l’Etape 1 : si le tableau n’est pas à jour, des éléments ne seront pas positionnés au bon endroit (généralement plus à gauche qu’ils ne devraient l’être) et seront donc traités trop tard lors du parcours du flux

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

Partager

Partager sur facebook
Partager sur twitter
Partager sur linkedin
Partager sur pinterest
Partager sur email
Partager sur whatsapp
Olivier MY

Olivier MY

Issu d'un cursus ingénieur, je me suis vite rendu compte que mes appétences et compétences tournaient plus autour de l'humain que de la technique. Je suis alors devenu Coach Agile et Coach Professionnel car j'ai toujours voulu contribuer à rendre le monde meilleur. J'accompagne aujourd'hui des individus, des équipes et des organisations vers une meilleure compréhension d'eux-mêmes afin de bâtir ensemble le futur qui leur correspond.

Commentaires

4 réflexions sur “Une alternative au Daily Scrum Meeting”

  1. Ping : Agilité@Scale

  2. 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Articles récents

Thalassagile

Thalass’Agile : une expérience réflexive hors du commun

Il y a des périodes où l’on a besoin de prendre du temps pour soi. Pour faire acte de ce que l’on a vécu, prendre …

LIRE PLUS
Teamwork

Team Building et Matrice Give and Take

Au cours d’une discussion avec Guy Lerat Jr qui me partageait ses aventures d’accompagnement, j’apprends qu’il va devoir organiser un Team Building important pour une …

LIRE PLUS
Photo by Jamie Templeton on Unsplash

Workshop : Améliorer sa posture de conseil

Dans le domaine du coaching Agile se pose souvent la question de la posture de coach. Dois-je être plutôt en posture basse (questionnement, prise de …

LIRE PLUS
Photo by Irina Iriser on Unsplash

L’échec du modèle Spotify

Il y a des articles comme cela qui chamboulent un peu les idées reçues et qui permettent de prendre un peu de recul. C’est le …

LIRE PLUS

Une expérience de facilitation à distance

Dans cette période de confinement où les interactions physiques sont limitées, nous sommes dans l’obligation d’animer nos ateliers à distance à l’aide d’une multitude d’outils. …

LIRE PLUS

Un atelier de clarification de rôle

Transformation Agile petite ou grande échelle, la question des rôles est une problématique assez commune. Pas qu’elle m’apparaisse comme normale, mais souvent car c’est la …

LIRE PLUS
Retour haut de page

Confidentialité et cookies : ce site utilise des cookies. En continuant à naviguer sur ce site, vous acceptez que nous en utilisions. Pour en savoir plus, y compris sur la façon de contrôler les cookies, reportez-vous à ce qui suit : Politique relative aux cookies.

Prenons contact