1. Définition et organisation

Un daily scrum meeting, daily stand-up meeting ou en abrégé ‘DSM’, est l’un des rituels “officiels” organisés de manière récurrente dans le cadre d’un processus de gestion de projets agile. Il s’agit d’une réunion où chaque participant se tient généralement par définition, debout, généralement devant le tableau du sprint afin de visualiser en temps réel les user stories en cours de développement, en attente ou encore en cours de conception UX/UI.

Dans la pratique, il ne devrait pas durer plus de 15 minutes. À la charge ensuite du Scrum Master de faire respecter ce délai. Généralement, on optera en guise de lieu de réunion, pour un emplacement réservé près des bureaux habituels de l’équipe, afin de rendre le daily scrum meeting plutôt informel. On privilégiera en effet la qualité des échanges plutôt que les conditions dans lesquelles ceux-ci sont abordés. Même si dans la pratique, ces conditions peuvent également avoir une influence sur l’efficacité de la communication lors des DSM. En effet, certains membres de l’équipe peuvent être également présents à distance, ce qui peut avoir un impact sur l’organisation, notamment à cause de la nécessité de se procurer un micro pour que cette personne puisse correctement participer à la réunion chaque jour avec le reste de l’équipe.

L’objectif de cette réunion quotidienne est de permettre de connaître l’avancement de l’équipe afin d’aboutir à la réalisation d’un ou plusieurs objectifs déterminés lors du sprint planning, en répondant aux 3 questions suivantes :

1.Qu’ai-je fait hier ?

Cette information pourra être utile aux Testeurs et au Product Owner car elle permettra de connaître l’avancement d’une ou plusieurs user stories et de déterminer celles qui sont testables. Elle sera aussi un indicateur du degré d’efficacité de l’équipe de développement et pourra jouer un rôle d’encouragement entre développeurs.

2.Que vais-je faire aujourd’hui ?

Cette question pourra donner de la visibilité à l’équipe, afin notamment de pouvoir prévenir les différentes parties prenantes d’un projet de l’avancée en temps réel du développement. C’est aussi une estimation du travail à accomplir sachant que celui-ci pourra être soumis aux aléas propres à la vie d’un projet ou d’un environnement applicatif de production. On peut citer par exemple les aléas liés aux incidents de production ou encore à des changements de besoin métier pouvant surgir tout au long de la journée.

3.Quels sont les points de blocage existants qui m’empêchent d’avancer ?

Cette question est fondamentale car elle permet à toute l’équipe d’avoir une vision transverse sur l’ensemble des points de contentieux attenants à une user story spécifique ou au projet global, et ce en toute transparence : une notion clé en agilité. En donnant cette visibilité, le développeur pourra donc faire prendre conscience de blocages parfois inconscients mais aussi encourager la recherche de solutions de déblocage de la part de l’ensemble des membres de l’équipe.

Il est également essentiel que dans la mesure du possible, tous les membres de l’équipe soient présents lors de ce rituel, et ce chaque jour. Dans la pratique, il s’agit essentiellement d’un rituel dédié aux équipes de développement, accompagnées du Scrum Master. La présence du PO étant optionnelle. Les parties prenantes peuvent venir mais seulement en tant qu’observateurs. L’objectif n’est pas tant d’instaurer une organisation rigide que de permettre une vélocité maximale de l’équipe sur chaque sprint afin de parvenir à la réalisation des objectifs du sprint. Le sentiment du travail accompli est donc aussi important pour la motivation de l’équipe, car il sera alors un des vecteurs essentiels d’une bonne productivité.

Attention cependant à ne pas rendre le daily stand-up meeting trop individualiste. En effet, un développeur pourrait être tenté d’aborder l’état de son avancement d’une manière très verticale sans essayer de communiquer vers les autres membres. C’est une erreur, car cela peut inhiber l’implication de l’équipe dans les projets sur lesquels l’ensemble de l’équipe (Scrum Master, Product Owner, Testeurs, Développeurs) peut être amenée à travailler. Dans l’idéal, l’intérêt du daily scrum meeting et de susciter la collaboration sur ces sujets communs.

2. Ses objectifs dans la démarche agile

Communiquer ! Tel serait le mot clé essentiel à garder en mémoire au moment de se demander pourquoi mettre en place un daily stand-up meeting au sein d’une équipe agile. En effet, contrairement à un cycle en V où le besoin est défini une fois pour toutes lors du cadrage initial, on ne peut pas dans un projet développé en agile, se permettre de ne pas communiquer un changement de besoin au développeur. En effet, le risque serait de se retrouver avec une fonctionnalité à tester qui ne correspondrait pas du tout aux critères d’acceptation rédigés par le PO et le Testeur à cause d’un manque ou absence d’informations. Un DSM réduit donc considérablement ces risques, en encourageant chaque membre de l’équipe à s’exprimer sur tout ce qu’il lui semble utile au bon développement d’un projet. En s’interrogeant ainsi, on peut donc plus aisément parvenir conjointement à trouver des solutions afin d’atteindre un objectif commun. Mais attention à ne pas tomber dans le piège d’un surplus d’informations. Par exemple : décrire un changement de besoin pendant un DSM n’est pas un moment approprié ! On attendra la fin de la réunion pour en discuter.

Rappelons dans le même temps qu’une fonctionnalité d’un projet se découpe en plusieurs user stories. Ces user stories sont développées par l’équipe tout au long des sprints, suivant leur planification en début de sprint. L’organisation d’un daily stand-up meeting permet alors à l’ensemble de l’équipe de connaître l’avancée et les éventuels blocages rencontrés par chaque personne (Développeur, Testeur, Product Owner). Cette démarche permet alors un suivi efficace des tâches en cours, nécessaires au développement de chaque user story.

Le DSM permet à toutes les parties prenantes de l’équipe travaillant sur un projet, de mieux anticiper certaines décisions nécessaires au bon avancement du projet. Comme par exemple, pour le Product Owner, d’informer un acteur métier d’un blocage au niveau du développement d’une fonctionnalité particulière, et donc d’un retard de livraison au bout de chaîne, au Testeur de connaître avec précision les product backlog items prêts à tester, ou encore à un autre Développeur de savoir que l’un de ses pairs a besoin d’aide afin de pouvoir terminer son développement.

3. Comment aller plus loin… avec l’exemple de la Fnac

Il est tout à fait possible et même recommandé de réfléchir à des moyens d’améliorer ses DSM. Vous pouvez alors par exemple vous servir des rétrospectives de fin de sprint pour en discuter. Par exemple, y consacrer 30 minutes sur une rétrospective de 2h. Autre solution : réfléchir à des ateliers afin de les améliorer. Avec l’aide du Scrum Master ainsi que de l’ensemble de l’équipe, il est tout à fait possible d’aboutir à un format d’atelier adapté pour toute l’équipe.

Julie Drouart, consultante Product Owner chez Fnac.com, un des leaders du e-commerce accompagné par Axance depuis de nombreuses années, a accepté de nous faire part de son retour d’expérience suite à la mise en place de plusieurs ateliers dans son équipe, après avoir constaté certains axes d’amélioration concernant l’organisation et la communication lors des DSM organisés dans son équipe.

1. Julie, peux-tu me décrire en 3 phrases courtes un DSM type dans votre équipe agile?

  • Le premier à vouloir parler doit se saisir du ‘totem de parole’
  • On commence par les Testeurs, puis chaque Développeur explique la tâche ou le bug sur lequel il travaille, et soulève les éventuels problèmes rencontrés.
  • Si besoin, on fait le point sur le board en abordant les codes review en attente, les tests à relancer, les blocages qui n’ont pas bougé depuis quelques temps afin de dégager des actions rapides.

2. Pourquoi avez-vous décidé de mettre en place ces ateliers ?

Tout est parti d’un constat : l’équipe connaissait des problèmes d’attention et de concentration lors des réunions, et notamment aux DSM le matin.

3. Brièvement, peux-tu me présenter en quoi consiste les ateliers que vous avez mis en place ?

La première étape a d’abord été de faire un tour de table pour avoir le ressenti de chaque membre. Plusieurs axes d’amélioration ont été identifiés. Par exemple, nous avons revu le temps de parole (mise en place de sablier, temps de parole réduit, préparation de sa prise de parole…), les « droits et devoirs » de chacun (par exemple, le Responsable et le Product Owner ne doivent pas poser de questions pendant la réunion, ni interrompre quelqu’un si le totem de parole n’est pas entre leurs mains), ainsi que les attentes de chacun. Enfin, nous avons également eu l’idée de filmer un DSM et de le visionner tous ensemble.

Deux objectifs :

  1. Sensibiliser à l’importance de la communication non verbale
  2. Mettre en avant l’importance de la qualité de l’élocution dans notre quotidien, notamment grâce à l’improvisation d’un monologue de 5 minutes sur un sujet au choix.

4. En quoi se sont-ils montrés utiles à l’équipe ? Quels résultats avez-vous pu obtenir ?

Ils ont été utiles dans la mesure où chaque personne a pu prendre conscience des points forts et des points faibles dans sa façon de communiquer (verbale et non verbale). En effet, certains se sont rendus compte qu’ils avaient des tics de parole très présents et qu’il leur était facile de les prévenir en préparant leur discours. D’autres avaient des mouvements qui venaient parasiter le discours et qu’il suffisait de bien se tenir pour mieux capter l’attention. Les réactions les plus compliquées à corriger se sont avérées être celles provoquées par la timidité (yeux fuyants, voix tremblante).

Conclusion

L’exemple de Julie à la Fnac, montre qu’un DSM doit être adapté au fonctionnement d’une équipe afin de pouvoir atteindre les objectifs de chaque sprint. Il ne faut donc pas hésiter à expérimenter avant de choisir la bonne formule. Les rétrospectives de fin de sprint sont aussi un bon moyen de discuter des axes d’amélioration de vos DSM. N’hésitez pas non plus à faire part d’originalité pour ‘animer’ ces rituels. Un petit objet qui passera de main en main permettra par exemple d’aider à mieux maîtriser le temps de parole de chacun. Finalement peu importe le moyen, la finalité reste d’encourager une communication et une écoute nécessaire afin de pouvoir être toujours plus réactif et proactif face à d’éventuels changements de besoin ou de user story, pour in fine être en mesure de mieux répondre aux attentes du client.

 

Article rédigé par Charles Paineau
Retrouvez-le sur Linkedin

 

Bibliographie :

https://www.atlassian.com/agile/scrum/standups