Si souvent, le concept même d’un Daily Meeting (ou Stand up Meeting) est relativement connu de tous, il n’en reste pas moins que sa raison d’être et son déroulé ne sont pas toujours très clairs, et pour les participants et pour leur écosystème. C’est d’ailleurs, de mon expérience, un des premiers sujets sur lequel un Scrum Master débutant demande des conseils ou bien une équipe lassée, de l'assistance.
Cet article n’a pas vocation à expliquer dans les grandes lignes ce qu’est un Daily, ni à quoi il sert, mais plutôt de donner des axes concrets sur la façon de le faciliter. Voici tout de même un rappel, à partir de ce que l’on peut trouver dans le Scrum Guide (ici en anglais et en français) :
"L’Équipe de Développement y planifie ses activités pour les prochaines 24 heures. Elle optimise la collaboration et la performance de l’équipe en lui permettant d’inspecter le travail effectué depuis la dernière Mêlée Quotidienne et de prévoir le travail à venir dans le Sprint. "
"L’Équipe de Développement utilise la Mêlée Quotidienne pour inspecter sa progression vers l’Objectif du Sprint et pour inspecter si ces progrès aident à finir le travail contenu dans le Backlog de Sprint. La Mêlée Quotidienne augmente la probabilité pour l’Équipe de Développement d’atteindre l’Objectif du Sprint. 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 et créer l’incrément d’ici la fin du Sprint."
Mais, s’il n’est pas facile en quelques mots de décrire ce qu’est un Daily, il est facile de dire ce qu’il n’est pas :
- Une remontée d'information, d'avancement, verticale vers un chef de projet.
- Une réunion qui dure.
- Une explication technique des fonctionnalités.
- Ce n'est pas le moment pour résoudre les problème mais seulement les évoquer, pour qu'à l'issue du Daily, les personnes concernées puissent les traiter.
D’ordinaire, le Daily suit un déroulé simple en trois questions posées à chaque participant de l’équipe de réalisation :
- Qu’ai-je fait hier qui a aidé l’Équipe de Développement à atteindre l’Objectif du Sprint ?
- Que vais-je faire aujourd’hui qui va aider l’Équipe de Développement à atteindre l’Objectif du Sprint ?
- Est-ce que je vois un obstacle qui m’empêche ou empêche l’Équipe de développement d’atteindre l’Objectif du Sprint ?
Mais là où le Guide Scrum ne parle que d’un exemple de trois questions, beaucoup d’équipes appliquent ce schéma à la lettre, sans chercher à en comprendre l’objectif, à le challenger et en adapter le format en fonction de leurs besoins.
Bien entendu cet article n'aurait pas lieu d’être si ce n’était pas pour parler d’une autre approche.
J’ai donc choisi ici de vous faire un retour sur celle que j’ai pu essayer : un daily non pas basé sur chaque membre individuellement, mais sur chaque US individuelle (qui dans l’idéal, décline l’objectif du sprint).
Pourquoi changer ?
Être acteur d'un système ne permet pas toujours de se rendre compte qu'il est perfectible. Car, finalement poser les trois questions du Scrum Guide n’est pas une mauvaise pratique ; dans l’équipe, nous les utilisions et elles nous permettaient d'atteindre le but du Daily Meeting. Du moins, c’était l’impression générale. Pourtant, il y avait quelques irritants dans le fonctionnement de l’équipe, rien de dangereux, mais parfois handicapant :
- Des US grosses et difficiles à découper.
- Une organisation du travail plutôt en silo, en parallèle que conjointe.
- Des membres de l’équipe impliqués, mais très concentrés sur leur partie du travail plutôt que la globalité. Sur ce qui a été fait plutôt que sur ce qu’il reste à faire.
- Beaucoup de sujets commencés, peu de terminés.
- Un manque de visibilité qui pouvait parfois, par inadvertance, laisser deux personnes travailler sur le même sujet, en doublon.
Le Daily dans sa forme habituelle pouvait-il nous aider à y remédier ? Sans doute pas tout à fait, mais j’ai eu envie de leur proposer quelque chose de nouveau, d’essayer, d’expérimenter.
Concrètement que s’est-il passé ?
Plutôt que d’être centrés sur chaque membre de l’équipe, nous nous sommes concentrés sur chaque US, en respectant leur priorisation. Nous nous sommes posés de nouvelles questions :
- Qu’est-ce qui est terminé ?
- Que manque t-il à cette US pour être terminée ?
- Qu’est-ce qui nous bloque pour la terminer ?
L’effet le plus visible, immédiat, a alors été de voir l’organisation du travail changer.
Puisque l’US était le sujet, chacun voyait mieux s’il manquait des tâches pour assurer sa réalisation (meilleur découpage).
En passant en revue toutes les US non terminées, il était plus facile de voir les blocages, les petits rien du tout (qui n’ont parfois de petit que le nom) qui empêchent de considérer un sujet comme terminé, ou simplement d’identifier les sujets sur lesquels personne ne travaillait alors que l’US était entamée. Non seulement les blocages devenaient plus visibles, mais l’équipe s’est organisée pour aller vers ces sujets, plutôt que de commencer une nouvelle US ou de continuer même si ce n’était pas leur domaine de prédilection (rédiger/passer des tests par exemple). De même pour se réorganiser en fonction des priorités.
L’objectif de livrer au plus vite une US a été remis au coeur du processus.
Le travail de plusieurs personnes sur un même sujet a été facilité et la tendance à avoir une seule personne par US s'est résorbée. De même, la situation où 2 personnes traitaient le même sujet sans s'en apercevoir ne s’est plus présentée.
Le Daily lui-même est devenu plus facile à suivre. Les participants étant moins focalisés sur leurs sujets, ils étaient du coup plus à l'écoute du reste du groupe. L’animation en était relativement facile, il fallait avant tout s’assurer que toutes les questions étaient posées, et bien demander ce qu’il manquait pour que l’US soit terminée.
Pour autant, ce n’est pas une solution miracle.
Pour l’appliquer, outre obtenir l’adhésion de l’équipe au système, il faut s’assurer qu’elle en ait bien compris les enjeux, car même si elle est convaincue, il est parfois plus simple de retourner à l’ancien fonctionnement par facilité.
Dans une équipe, qu’elle soit récemment formée, ou qu’elle n’ait pas l’habitude de travailler ensemble, il faut être attentif à l’équilibre dans la répartition des tâches entre les membres. La conversation n’étant plus orientée sur une personne, il est facile de passer à côté de quelqu’un qui fournirait trop (ou pas assez) de travail. Charge pour le SM (et l’équipe) alors d’y être vigilant.
En résumé, cette approche a incité les membres de l’équipe à mieux travailler ensemble, de mieux collaborer, de savoir où elle allait, de casser ses silos internes.
Mais il faut garder à l’esprit un des enseignements de l’agilité. Une même façon de faire ne peut être universelle, elle ne peut être la réponse unique à des équipes/questions/situations différentes. Ce format, bien qu’il ait été efficace dans cette équipe, ce contexte, ne doit pas être retenu comme la nouvelle façon de faire par défaut.
Discutez avec les autres membres de l’équipe. Identifiez à quels besoins de l'équipe le Daily doit répondre. Essayez, quitte à vous dire que non, définitivement, vous étiez mieux avant. Qui sait, vous serez peut être mieux après.
