Le flux de valeur

Le Sprint

Un journal hebdomadaire paraît le jeudi, que la semaine ait été riche ou pauvre en nouvelles. La date ne bouge pas, et c'est le contenu qui s'ajuste. Scrum organise le travail de la même façon, par périodes de durée fixe appelées Sprints. Cet article présente les patterns qui décrivent le Sprint, son objectif, la période de production qu'il protège et le rythme qu'il installe.

Une durée fixe, un contenu qui s'ajuste

Dans A Scrum Book (2019), Jeff Sutherland, James Coplien et leurs coauteurs décrivent Scrum par des patterns, c'est-à-dire des solutions éprouvées à des problèmes récurrents, présentées avec les forces qui s'y opposent. Le pattern Sprint part de trois constats. Dans un travail complexe, l'équipe risque toujours de résoudre le mauvais problème, et seuls des retours fréquents limitent ce risque. Une équipe ne s'installe pas dans une livraison régulière sans cadence, et les personnes ont besoin de repères pour constater qu'elles avancent. Enfin, le Product Backlog, la liste ordonnée de tout ce qui reste à faire, convient pour voir loin, mais les développeurs, c'est-à-dire ceux qui réalisent le travail, doivent à un moment se concentrer sur une tranche de cette liste et la mener à terme.

La solution est d'organiser le travail en intervalles récurrents, fréquents et de durée fixe. Le Sprint est à la fois une durée, pendant laquelle l'équipe produit, et une cadence, qui jalonne le calendrier. Sa longueur maximale est d'un mois. Les auteurs observent que deux semaines sont devenues la pratique dominante. En s'appuyant sur Donald Reinertsen (The Principles of Product Development Flow, 2009), ils ajoutent qu'une cadence régulière empêche les écarts de s'accumuler d'une période à l'autre.

Chaque Sprint suit le même déroulement. Il s'ouvre par le Sprint Planning, où l'équipe choisit un objectif et bâtit son plan. Vient ensuite la période de production, ponctuée chaque jour par le Daily Scrum. Il se termine par la Sprint Review, où l'on examine le produit, puis par la Sprint Retrospective, où l'équipe examine sa façon de travailler.

Les auteurs proposent de voir le Sprint de trois façons. C'est une unité de temps, et donc de coût, puisqu'une équipe stable coûte la même somme à chaque Sprint. C'est une unité de livraison, qui produit un incrément, c'est-à-dire une version utilisable et enrichie du produit. C'est aussi une unité d'apprentissage, comme une leçon de piano hebdomadaire.

Une règle ne souffre pas d'exception dans le pattern : quand le Sprint est fini, il est fini, et on ne le prolonge jamais pour achever un travail en cours. Les auteurs présentent cette borne comme un espace que les développeurs gèrent eux-mêmes, et non comme un moyen de les presser.

Le Sprint Goal donne la raison du travail

Suivre une liste de tâches ne garantit pas que l'on crée de la valeur. C'est le problème du pattern Sprint Goal (objectif du Sprint). Quand le plan n'est qu'une liste, chacun prend sa ligne et travaille seul, et l'équipe perd ce que ses membres s'apporteraient en travaillant ensemble. De plus, le plan ne survit pas intact au Sprint : du travail imprévu apparaît, ou il devient clair que tout ne sera pas terminé. Il faut alors replanifier vite, et pour cela disposer d'un critère.

La solution est que la Scrum Team (les développeurs, le Product Owner et le Scrum Master) s'engage sur un court énoncé de la valeur qu'elle veut créer pendant le Sprint, et que tout le travail s'y rapporte. L'objectif se formule en commun, sous la conduite du Product Owner, le responsable de la valeur du produit. Les développeurs doivent pouvoir expliquer comment ils l'atteindront, et l'énoncé reste affiché. Les auteurs attribuent la première description du Sprint Goal à Ken Schwaber et Mike Beedle, en 2001.

Jeff Sutherland rapporte un cas observé en 2007 chez Palm. Des équipes s'essoufflaient sur des éléments techniques dont elles ne voyaient pas l'utilité. Une fois le lien rétabli avec l'objectif du Sprint, qui était d'améliorer de 10 % les performances du système, la motivation est revenue. Ce récit est un témoignage, non une mesure.

Le Production Episode, un temps protégé

Le pattern Production Episode (épisode de production) désigne la partie du Sprint située entre le Sprint Planning et la Sprint Review. Il répond à un problème de concentration. Une information qui arrive au bon moment aide les développeurs, mais chaque interruption leur coûte du temps pour reprendre le fil. Selon les auteurs, une liste de travail accompagnée d'une échéance imposée de l'extérieur dégrade la motivation et la qualité. Ils s'appuient sur une étude de Teresa Amabile et ses collègues (1976), qui a mesuré l'effet de ces échéances sur la motivation intrinsèque, et non sur la qualité du travail. L'absence de toute échéance ne vaut pas mieux : selon la loi énoncée par C. Northcote Parkinson en 1955, le travail s'étend jusqu'à occuper tout le temps disponible.

La solution est de réserver aux développeurs un intervalle borné et protégé. Le Product Owner et les développeurs conviennent que le premier n'ajoute ni ne modifie aucun élément pendant cet intervalle. Il reste libre de réordonner le Product Backlog, mais ses changements ne prennent effet qu'au Sprint Planning suivant. De leur côté, les développeurs ont eux-mêmes choisi la quantité de travail, sous la forme d'une prévision et non d'une promesse. S'ils finissent en avance, ils prennent l'élément suivant en haut du Product Backlog. Si le plan est menacé, ils se replient sur le Sprint Goal.

Dans les cas exceptionnels où l'objectif devient inatteignable, le Product Owner peut écourter le Sprint, ce que décrit l'article Protéger le Sprint des interruptions.

Fixed Work, ou compter à part ce qui ne s'estime pas

Tout le travail d'une équipe ne se prête pas à l'estimation. Personne ne peut dire combien de temps il faudra pour comprendre un besoin mal défini ou pour avoir une idée. Si ce travail est mêlé au plan du Sprint, les prévisions perdent leur fiabilité. Le pattern Fixed Work (travail fixe) propose de séparer deux catégories. Le travail sur le produit, que les développeurs savent estimer, remplit le Production Episode. Le travail qui ne s'estime pas reçoit des plages de durée fixe, hors de ce budget : le Sprint Planning, la Sprint Review, la Sprint Retrospective et les séances de préparation du Product Backlog. On y fait ce qui tient dans la plage, et si l'on a fini plus tôt, on passe à la suite.

Un calcul montre ce que cela représente. Dans un Sprint de deux semaines à 35 heures, chaque personne dispose de 70 heures. Comptons à titre d'exemple 4 heures de Sprint Planning, 2 heures de Sprint Review, 1 heure 30 de rétrospective, dix Daily Scrums d'un quart d'heure (2 heures 30) et 7 heures de préparation du Product Backlog. Le travail fixe occupe 17 heures. Il reste 53 heures pour la production, soit environ les trois quarts du Sprint.

Rythme et calendrier

La note Rhythms: Patterns of Time (rythmes : les patterns du temps) défend une idée simple : pour certaines activités, la régularité compte plus que la fréquence. On se brosse les dents à heure fixe sans y réfléchir. De même, une équipe dont les rendez-vous reviennent à cadence connue n'a plus à se demander quand elle se réunira et peut se consacrer au contenu. Les auteurs conseillent donc d'installer d'abord une cadence, puis d'ajuster la durée et la fréquence de chaque événement. Ils s'appuient sur l'anthropologue Edward T. Hall (The Dance of Life, 1983).

Le pattern Follow the Moon (suivre la lune) prolonge cette idée. Les personnes ne produisent pas la même chose chaque jour de l'année, et les fêtes, les congés et les habitudes locales bousculent un calendrier de Sprints tracé à la règle. La solution proposée est de caler le début et la fin des Sprints sur la nouvelle lune et la pleine lune, et de bâtir avec l'équipe un calendrier à long terme qui tient compte des congés et des fêtes. Les auteurs classent eux-mêmes ce pattern parmi les pratiques avancées et demandent de l'appliquer avec bon sens.

L'ajustement à la lune n'est qu'approximatif, puisque le mois lunaire dure environ 29,5 jours et non 28. La partie la plus utile du pattern est sans doute le calendrier établi en commun. Pour l'équipe d'enseignants, l'année scolaire est déjà découpée en périodes séparées par des vacances : une période de sept semaines accueille trois Sprints de deux semaines, et la semaine restante sert aux conseils de classe et au bilan.

Team Sprint : un Sprint dont les développeurs choisissent le contenu

Le pattern Team Sprint (Sprint de l'équipe, aussi appelé Hack Sprint) traite une frustration. Les développeurs ont des idées pour améliorer le produit, leurs outils ou leur cadre de travail. Ces idées entrent dans le Product Backlog, mais des demandes jugées plus rentables passent toujours devant. Le Product Owner peut aussi sous-estimer des propositions dont l'intérêt n'apparaît qu'une fois réalisées. À la longue, l'équipe se décourage de n'avoir aucune prise sur son travail.

La solution est que le Product Owner organise, tous les cinq ou dix Sprints par exemple, un Sprint entier dont les développeurs choisissent les éléments et l'objectif. Les éléments passent tout de même par le Product Backlog, pour que le travail reste visible. Le pattern interdit un usage : le Team Sprint ne sert pas à rattraper un retard ni à corriger des négligences de qualité accumulées, car la qualité se tient à chaque Sprint. Les auteurs citent le témoignage de Gabrielle Benefield, qui a introduit ces Sprints chez Yahoo! en 2003 parce que des équipes trouvaient le rythme de Scrum implacable.

Ce que dit le Guide Scrum 2020

• Le Guide décrit le Sprint comme un événement de durée fixe, d'un mois au plus, et précise qu'un nouveau Sprint commence dès la fin du précédent. Il concorde ici avec le pattern.
• Depuis 2020, le Sprint Goal est l'engagement associé au Sprint Backlog, et le Sprint Planning s'ouvre sur la question de savoir pourquoi ce Sprint a de la valeur.
• Le Guide est plus souple que le Production Episode. Il interdit les changements qui mettraient le Sprint Goal en danger et toute baisse de la qualité, mais il admet que le périmètre soit clarifié et renégocié avec le Product Owner à mesure que l'équipe apprend.
• Le Guide prévoit qu'un Sprint peut être annulé si son objectif devient obsolète, et que seul le Product Owner en a l'autorité.
• Les termes Production Episode, Fixed Work, Team Sprint et Follow the Moon sont propres au livre. Celui-ci écrit « Development Team » là où le Guide 2020 dit « Developers ».

Limites et pièges

Le mot Sprint évoque une course à pleine vitesse, et certaines organisations le prennent au pied de la lettre. Le Guide Scrum parle pourtant d'un rythme soutenable.

Deux dérives vident le Sprint de son sens. La première est le Sprint en cascade, où l'on analyse la première semaine, on réalise la seconde et on vérifie le dernier jour. La seconde est la prolongation de deux jours pour terminer : elle paraît raisonnable, mais elle détruit la cadence et rend les mesures incomparables d'un Sprint à l'autre. Un objectif réduit à « finir les quatorze éléments prévus » pose un autre problème, puisqu'il ne fournit aucun critère pour replanifier.

Le gel du périmètre peut aussi être appliqué avec raideur : refuser une correction urgente au nom du Sprint dessert les usagers. À l'opposé, un Product Owner qui modifie le plan tous les deux jours retire aux développeurs le temps protégé qui justifie le dispositif.

Le Sprint ne convient pas à tous les travaux. Une équipe d'assistance dont les demandes arrivent sans prévenir s'accommode souvent mieux d'un flux continu. Quant aux bénéfices de la cadence, ils reposent sur l'expérience des auteurs et sur des travaux généraux consacrés au rythme et à la motivation, non sur des comparaisons contrôlées. L'article Critiques et état des preuves revient sur cette distinction.