Pour des Daily Scrum efficaces

Note : Dans les articles de blog où je parle de Scrum, j'ai décidé de conserver le vocabulaire officiel qui est en anglais. J'espère que les éventuelles visiteurs réfractaires aux anglicismes me pardonneront :-)

Quand on parle de Scrum, l'une des premières choses qui vient à l'esprit est le Daily Scrum. Souvent, on trouve même des pratiques de Daily Scrum dans des équipes ou des organisations qui ne pratiquent pas Scrum. Cet événement est parfois aussi appelé Daily Meeting, ou Stand-Up Meeting, mais son nom officiel est bel et bien le Daily-Scrum.

Le Daily Scrum, c'est quoi ?

Un Daily Scrum a lieu, comme son nom l'indique, tous les jours. C'est une sorte de micro-réunion qui permet de faire un point sur le Sprint Backlog en cours entre développeurs, et d'en identifier les difficultés. Cela permet alors d'évaluer l'état d'avancement par rapport au Sprint Goal qui a été défini, afin de planifier la prochaine journée de travail.

Le Daily-Scrum permet notamment de créer du focus, l'une des principale valeurs nécessaires à Scrum pour son bon fonctionnement. Cela permet à chacun de savoir sur quelle tâche il faut se concentrer en priorité. Il permet également d'améliorer la communication et la transparence au sein de l'équipe, en facilitant la transmission d'informations importantes.

Voici les points d'organisation importants du Daily-Scrum:

• Il doit avoir lieu tous les jours de travail
• Il doit avoir une durée maximale de 15 minutes
• Il s'agit d'une réunion entre développeurs
• Le Daily-Scrum doit permettre de définir un plan d'action pour la prochaine journée de travail

Idéalement, le Daily-Scrum devrait toujours avoir lieu à la même heure et au même endroit, mais ce n'est pas une obligation. Cela permet cependant de fluidifier son déroulement, car chacun sait ainsi où et à quelle heure il a lieu.

Le Daily Scrum, ce n'est pas...

Le Scrum-Guide défini de manière claire ce qu'est le Daily Scrum. Mais il ne dit pas vraiment ce qu'il n'est pas. Pourtant, je trouve important de comprendre les choses à ne pas faire pendant un Daily Scrum.

Le point qui est selon moi le plus important, est que le Daily-Scrum n'est pas un moment pour faire son rapport d'activité au chef, au Product Owner ou au Scrum Master. Le Daily-Scrum est une réunion prévue pour les développeurs, afin qu'ils inspectent l'état d'avancement du Sprint, et qu'ils se mettent d'accord sur la suite.

Pour le dire autrement, si le Product Owner ou le Scrum Master ne participent pas activement en tant que développeurs au projet, ils n'ont pas à être présents lors du Daily Scrum. Ce n'est pas leur place. En fait, l'unique rôle du Scrum Master dans le cadre du Daily Scrum est de s'assurer que celui-ci a bien lieu, et qu'il ne dépasse pas 15 minutes.

Le Daily-Scrum n'est pas non plus le moment où on fait des démos, où on essaie de régler tous les problèmes. Il permet certes de signaler les difficultés rencontrées, mais il ne faut pas chercher à tout régler immédiatement. Évidemment, si un point soulevé peut être discuté rapidement, autant en profiter. Mais si le problème est plus compliqué ou demande de l'analyse, alors il doit se régler avec les personnes concernées après le Daily Scrum.

D'après une ancienne version du Scrum Guide, les développeurs devaient, pendant le Daily Scrum, répondre à trois questions essentielles :

Ces 3 questions se sont révélées beaucoup trop restrictives, voire même inefficaces, et elles ont donc été retirées de la nouvelle version du Scrum Guide.

Certaines équipes sont cependant habituées à ces questions, et y trouvent de l'intérêt. Elles peuvent sans problème continuer à les utiliser, rien ne l'interdit. Mais à titre personnel, je trouve ces 3 questions totalement inefficaces, car elles demandent implicitement à chacun de justifier le travail accompli jusque là.

Les gens parlent donc pour montrer qu'ils ont bien travaillé, pour justifier le temps investi dans leurs tâches. Cela n'a absolument aucun intérêt pour le projet. Nous ne sommes pas dans un compte-rendu d'activité. En outre, je trouve l'utilisation de ces 3 questions très chronophage car chacun doit prendre la parole, et la durée maximale de 15 minutes devient très difficile à respecter.

Enfin, d'un point de vue organisationnel, le Scrum Guide ne fixe que très peu de règles. Ainsi, même si le Daily-Scrum peut être fait sous la forme de Stand-Up Meeting, où chacun reste debout, ce n'est en aucun cas une obligation.

Comment animer un Daily Scrum efficace ?

Venons-en à la question principale : comment faire en sorte que le Daily-Scrum soit efficace, apporte une vraie plus-value, et qu'il tienne en 15 minutes ? La méthode que j'utilise est simple. Et ce n'est pas moi qui l'aie inventée, je préfère le préciser tout de suite :) Je vais essayer de la décrire ci-dessous.

En général, chaque équipe Scrum utilise un tableau Kanban pour afficher ses tâches. Le tableau Kanban permet de déplacer les tâches de gauche en droite, en général pour aller du statut ouvert au status fermé, en passant par d'autres statuts comme par exemple en cours, en revue, ou à valider. On a ainsi à n'importe quel moment une vision de l'état d'avancement du Sprint. Cela ressemble à ceci :

Pour un Daily-Scrum efficace, l'idée est de chaque jour passer le tableau en revue en commençant par la colonne la plus à droite, et en allant vers la gauche.

Ainsi, on commence par parler rapidement des tâches qui ont été nouvellement fermées. Y a-t-il des précisions à apporter ? Une information spéciale à donner ? Ces tâches étant fermées, il n'y a en général pas grand-chose à dire. Et si beaucoup de temps est nécessaire pour rediscuter ces tickets, cela signifie probablement qu'elles ne devraient pas être fermées, et qu'il y a quelque-chose à revoir dans le processus de gestion des tickets, ou dans la "Definition of Done".

On passe ensuite aux tâches présentes dans la colonne précédente. Dans cet exemple, il s'agit de la colonne à valider. Ici encore, pas besoin de s'attarder. Une tâche à valider doit déjà être assignée à une personne, et donc l'équipe est en attente d'un retour. Si une tâche reste trop longtemps dans cet état, le Daily Scrum est le moment de comprendre pourquoi cette tâche est bloquée ici, et de voir ce qu'on peut faire pour la débloquer, en envoyant une relance par exemple.

On continue ainsi de suite, de droite à gauche, jusqu'à arriver à la colonne en cours. Là, il est inutile de discuter toutes les tâches. Le travail est en cours, ce n'est pas la peine que chacun explique tout ce qu'il est en train de faire, comment et pourquoi. Personnellement, à ce moment-là je pose les deux questions suivantes :

Un développeur qui n'a pas de problème particulier n'est pas obligé d'expliquer ce qu'il a fait la veille. Nous lui faisons confiance, nous savons qu'il fait de son mieux, et que s'il rencontre un problème il le dira.

Un développeur qui ne pense pas pouvoir terminer sa tâche pour le lendemain n'a pas non plus à expliquer pourquoi, ce qui lui prend peut-être plus de temps que prévu, etc... Nous lui faisons confiance, nous savons qu'il fait de son mieux, et qu'il nous dira quand sa tâche pourra être terminée.

Enfin, les tâches qui sont encore en statut ouvert, dans la colonne la plus à gauche, n'ont à priori pas besoin d'être discutées.

Depuis que nous faisons nos Daily Scrum de cette manière, plus personne ne se sent obligé de parler pour ne rien dire, et nous ne dépassons que très rarement les 15 minutes (même si cela arrive encore de temps en temps, je ne vais pas mentir).

Une dernière précision

Ceci n'est pas une recette miracle. Aujourd'hui dans notre équipe, tout le monde s'entend bien, il n'y a pas de conflit, et la répartition des tâches est facile. Cela fait également plusieurs années que nous évoluons ensemble dans le framework Scrum. Nous avons donc pu expérimenter d'autres pratiques avant, et nous avons compris ensemble pourquoi elles ne marchaient pas bien pour nous. C'est ce qui nous a amené vers cette solution, qui pourrait moins bien fonctionner dans une autre équipe.

Scrum nous dit une chose essentielle : La base de toute décision est l'empirisme. Et l'empirisme repose sur l'expérience, pas sur la théorie. C'est donc à chaque équipe de se faire ses propres expériences, puis de faire évoluer sa pratique afin de trouver l'organisation qui lui convient le mieux.

Il n'y a pas de solution universelle.