Le flux de valeur

Le Daily Scrum

Le Daily Scrum est l'événement de Scrum le plus connu, et aussi le plus souvent détourné. Beaucoup d'équipes en font un tour de table où chacun rend compte de sa veille. Le pattern décrit autre chose : quinze minutes pendant lesquelles les développeurs refont leur plan pour atteindre l'objectif du Sprint. Cet article explique ce que demande le pattern, d'où viennent les « trois questions » et pourquoi le Guide Scrum les a retirées en 2020.

Un tour de table qui n'aide personne

Tout le monde a parlé et la liste est à jour, mais rien n'a été décidé. Le plan de l'équipe est le même qu'avant la réunion, Inès est toujours bloquée, et deux personnes se gênent sans le savoir. Chacun s'est adressé à Karim plutôt qu'à ses collègues. Cette scène est celle que le pattern Daily Scrum (la mêlée quotidienne) cherche à éviter. Il figure dans A Scrum Book (2019) de Jeff Sutherland, James Coplien et leurs coauteurs, où chaque pattern expose un problème récurrent, les forces en présence et une solution éprouvée par des praticiens.

Un plan périmé dès le lendemain

Le pattern se place au moment où l'équipe a commencé son Sprint, la période de travail de durée fixe qui rythme Scrum. Elle dispose d'un Sprint Goal (l'objectif du Sprint) et d'un Sprint Backlog (le plan de travail des développeurs), tous deux issus du Sprint Planning, la réunion qui ouvre le Sprint. Les auteurs rappellent le mot du maréchal prussien Helmuth von Moltke, pour qui aucun plan d'opérations ne reste sûr au-delà de la première rencontre avec l'ennemi. Le plan établi au début du Sprint vieillit de la même manière, et le pattern en donne les raisons.

• Dans un travail complexe, les tâches changent sans cesse. Des tâches cachées apparaissent, un besoin se révèle mal compris, deux développeurs dépendent l'un de l'autre, un obstacle bloque quelqu'un ou un collègue est absent.
• L'ordre des tâches compte. Les auteurs calculent que cent tâches peuvent se ranger d'environ 9 × 10¹⁵⁷ façons, dont très peu rendent le travail fluide. Le bon ordre d'hier n'est plus celui d'aujourd'hui.
• Replanifier trop souvent fait perdre du temps et étouffe les développeurs. Replanifier trop rarement laisse durer les blocages et entretient un plan qui ne décrit plus la réalité.
• Une personne seule décide vite, mais une décision d'équipe demande la présence de tous ceux qu'elle touche. Celui qui a un problème à soumettre au groupe ne trouve pas facilement le moment de le faire.

Quinze minutes pour replanifier

La solution du pattern est de tenir chaque jour un événement court pour replanifier le Sprint, afin d'augmenter les chances d'atteindre le Sprint Goal d'abord, et de terminer tous les éléments du Sprint Backlog ensuite. L'ordre de ces deux buts a son importance, puisque l'objectif passe avant la liste. La réunion porte sur le travail du jour, sans perdre de vue le reste du Sprint.

Plusieurs règles accompagnent cette solution. La durée est limitée à quinze minutes, et l'équipe se discipline elle-même pour la tenir. Beaucoup d'équipes restent debout pour s'en souvenir. Tous les développeurs sont présents, et un absent n'envoie pas de remplaçant. La réunion sert à décider, non à résoudre les problèmes : quand un obstacle est signalé, les personnes concernées conviennent de se voir ensuite, sans retenir les autres, et rendent compte le lendemain. Si l'équipe dépasse régulièrement le quart d'heure, les auteurs y voient le signe d'un défaut à corriger dans sa façon de travailler.

Le résultat est un Sprint Backlog mis à jour. Les tableaux et les graphiques affichés au mur le sont aussi, mais le pattern précise que cette information est un sous-produit. Il le dit sans détour : le Daily Scrum est une réunion de replanification et non une réunion d'état d'avancement. La question de fond est de savoir si l'équipe atteindra son objectif.

Les auteurs attribuent au Daily Scrum d'autres effets : les obstacles deviennent visibles chaque jour, les occasions de s'entraider apparaissent, et le rituel quotidien renforce l'identité de l'équipe. Ils en racontent aussi l'origine. James Coplien avait étudié au début des années 1990 l'équipe qui développait le tableur Quattro Pro pour Windows chez Borland, et qui se réunissait chaque jour. La première équipe Scrum a repris cette pratique en février 1994. Selon le récit rapporté dans le pattern, elle a pris en mars la même quantité de travail que le mois précédent et l'a terminée dès la première semaine. Ce récit concerne une seule équipe et vient des auteurs eux-mêmes. Il ne constitue pas une mesure.

Les trois questions

Pour replanifier, il faut savoir où l'on en est. Le pattern présente comme une technique répandue le fait que chaque développeur réponde à trois questions : ce qu'il a fait la veille qui a aidé l'équipe à atteindre le Sprint Goal, ce qu'il fera aujourd'hui dans le même but, et les obstacles qu'il voit sur le chemin de cet objectif. Dans le livre, ces questions servent à préparer la décision.

L'histoire du Guide Scrum, rédigé par Ken Schwaber et Jeff Sutherland, montre un recul progressif de ces questions. Les premières éditions en faisaient le contenu de la réunion. La révision de 2013 les a reformulées autour du Sprint Goal, en soulignant que le Daily Scrum était trop souvent perçu comme une réunion d'état d'avancement. L'édition 2017 ne les donnait plus que comme un exemple possible. L'édition 2020 les a supprimées, dans le cadre d'un allègement général des prescriptions. Elle laisse les développeurs choisir la structure et les techniques qu'ils veulent, à deux conditions : la réunion porte sur la progression vers le Sprint Goal, et elle produit un plan concret pour la journée de travail à venir.

Ce retrait se comprend en relisant la première scène. Posées à chacun tour à tour, les trois questions produisent une suite de comptes rendus individuels, adressés à celui qui anime. Elles restent utilisables si l'équipe s'en sert pour décider. Une autre pratique courante consiste à parcourir le tableau élément par élément, en commençant par ceux qui sont le plus près d'être terminés, et à se demander ce qu'il faut pour finir chacun.

La réunion des développeurs

Le pattern est net sur ce point : le Daily Scrum est la réunion des développeurs. D'autres personnes peuvent y assister si les développeurs les invitent, mais eux seuls y participent activement. La règle vaut aussi pour le Product Owner, le responsable de la valeur du produit. Les auteurs reconnaissent que la transparence plaide pour une réunion ouverte, tout en observant que la seule présence d'un tiers modifie ce qui s'y dit.

Le cas du Scrum Master est traité à part. Il peut assister à la réunion, surtout dans les débuts, pour aider l'équipe à tenir la durée. Mais les développeurs se mettent souvent à le traiter comme un chef, et la réunion glisse vers le compte rendu. Le pattern ScrumMaster Incognito (le Scrum Master incognito) décrit ce problème : les développeurs s'adressent au Scrum Master, attendent son accord avant d'agir et ne se comportent plus en équipe. La solution est que le Scrum Master fasse en sorte que l'équipe s'approprie la réunion. Il peut se placer derrière la personne qui lui parle, quitter discrètement la pièce ou expliquer pourquoi cette appropriation compte.

Le Guide Scrum 2020 va dans le même sens avec une nuance. Il définit le Daily Scrum comme un événement de quinze minutes pour les « Developers » (le livre écrit encore « Development Team »), tenu à la même heure et au même endroit chaque jour ouvré. Il ajoute que le Product Owner ou le Scrum Master y participent en tant que développeurs s'ils travaillent eux-mêmes sur des éléments du Sprint Backlog.

Hors du logiciel, dix minutes devant le tableau des lits

On retrouve dans cet exemple les traits du pattern : un objectif commun, un état des lieux tourné vers ce qui empêche de l'atteindre, et des décisions prises par ceux qui font le travail. Les problèmes eux-mêmes se règlent après la réunion.

Limites et pièges

La dérive en réunion de reporting est le piège principal. Elle se reconnaît à quelques signes : les regards vont vers une seule personne, les phrases commencent par « hier, j'ai », un responsable pose des questions, et personne ne change de plan en sortant. Le compte rendu d'activité rassure celui qui le reçoit, mais il n'aide pas l'équipe à atteindre son objectif.

D'autres défauts sont fréquents. Certaines équipes résolvent les problèmes en séance, et le quart d'heure devient trois quarts d'heure. D'autres attendent le lendemain matin pour signaler un blocage survenu à 10 heures, alors que le Guide Scrum 2020 rappelle que les développeurs peuvent ajuster leur plan à tout moment de la journée. Quand les tâches durent plusieurs jours chacune, rien ne bouge d'un matin à l'autre et la réunion tourne à vide, comme le relève le pattern Small Items (petits éléments).

Les auteurs signalent enfin une confusion répandue, qui consiste à croire qu'une équipe « fait du Scrum » parce qu'elle tient une réunion debout chaque matin. Ils la comparent au fait de taper dans un ballon dans un parc, qui ressemble au football sans en être.

Sur l'efficacité de la pratique, la recherche disponible invite à la nuance. Viktoria Stray, Dag Sjøberg et Tore Dybå ont étudié douze équipes de développement dans trois entreprises, à partir de soixante entretiens et de soixante-dix-neuf réunions observées (Journal of Systems and Software, 2016). Les participants appréciaient surtout le partage d'information et la possibilité de discuter des problèmes et de les résoudre, ce qui nuance la règle du pattern sur ce point. Ils reprochaient à la réunion de servir de compte rendu au responsable, d'être trop fréquente et de durer trop longtemps. Cette étude qualitative ne mesure pas un gain de productivité. Elle indique en revanche que le compte rendu au responsable est l'une des principales causes de rejet de la réunion. L'article Critiques et état des preuves replace ces résultats dans un cadre plus large.