Le flux de valeur

Plan de livraison et feuille de route

Les parties prenantes veulent savoir ce qui sera livré et à quelle date. Scrum ne peut pas le garantir, mais il permet de le prévoir honnêtement à partir de ce que l'équipe a réellement livré jusque-là. Dix patterns d'A Scrum Book traitent de cette prévision, des contraintes de calendrier qui s'y imposent et des contrats qui laissent une place au changement.

« J'ai besoin d'une date »

Dans un organisme de formation, une équipe de cinq formateurs produit les modules du catalogue de rentrée par Sprints de deux semaines. La directrice interroge la Product Owner.

« Le catalogue sera-t-il complet le 1^er septembre ? »

« Je peux vous montrer ce que nous avons terminé pendant les cinq derniers Sprints et ce que cela annonce. Je ne peux pas vous garantir une date pour l'ensemble. »

« J'ai besoin d'une date pour l'imprimeur. »

« Alors je vous donne deux choses : la liste des modules qui seront prêts à coup sûr le 1^er septembre, et une fourchette pour les autres. »

Cette réponse applique les deux premiers patterns de cet article.

Release Plan : lire les livraisons dans le Product Backlog

Le pattern Release Plan (plan de livraison) suppose un Product Backlog estimé et une vélocité connue. Le Product Owner doit pouvoir dire quand sortira la prochaine version et ce qu'elle contiendra. La contrainte principale est tantôt la date, tantôt le contenu. Imposer les deux à la fois crée un problème surcontraint, dont le Product Owner doit rendre le risque visible. Sans accord sur le contenu, les demandeurs croient pouvoir en ajouter jusqu'au dernier jour, et la livraison recule. Un plan écrit par le Product Owner seul ignore ce que savent les développeurs, qui ne s'y sentiront pas engagés.

La solution est de bâtir avec les développeurs un Product Backlog qui exprime la suite d'incréments menant à la vision, puis de le lire comme un plan. On part du haut de la liste et l'on additionne les estimations jusqu'à atteindre la vélocité d'un Sprint. Ces éléments forment la prochaine livraison, et l'on continue vers le bas. Le calcul inclut tout le travail nécessaire pour atteindre l'état Done, sans phase de finition séparée. Les auteurs posent deux garde-fous. Au-delà de trois Sprints, la prévision relève davantage de la conjecture que de la projection. Et aucune date du plan ne doit être lue comme un engagement ferme.

Release Range : annoncer une fourchette

Le pattern Release Range (fourchette de livraison) répond à une habitude tenace : une date unique est prise pour une promesse. Une estimation n'est pourtant que la meilleure supposition du moment. Un membre de l'équipe tombe malade, un problème résiste, la vélocité évolue. Demander à l'équipe un chiffre optimiste et un chiffre pessimiste pour chaque élément prend du temps et repose sur des impressions.

La solution tire la fourchette de l'historique. On relève la vélocité la plus basse et la plus haute des trois à cinq derniers Sprints. On divise le total des estimations à livrer par chacune des deux, ce qui donne une échéance pessimiste et une échéance optimiste. Le même calcul, mené à date fixe, donne une fourchette de contenu. Les auteurs comparent cette pratique aux prévisions de floraison des cerisiers au Japon, annoncées chaque année par plages de dates. Ils déconseillent de communiquer la seule borne pessimiste, qui serait reçue comme un engagement.

Product Roadmap et Set-Based Design : garder des options ouvertes

Le pattern Product Roadmap (feuille de route du produit) part du fait que plusieurs chemins mènent au but et qu'on ignore d'avance lequel est le meilleur. S'accrocher à un plan unique conduit à l'épuisement quand la réalité s'en écarte. Un bon Product Owner garde des solutions de rechange, mais le Product Backlog n'a qu'une dimension et ne montre qu'un seul ordre de livraison. La solution est une feuille de route dessinée comme un graphe, avec des points de décision et des branches, annotée des coûts et des valeurs connus. Le Product Backlog devient la meilleure hypothèse du jour sur le chemin à suivre dans cette carte, et le plan de livraison s'en déduit. Les auteurs veulent une feuille de route simple, limitée aux choix stratégiques, qui montre des alternatives et des dépendances plutôt qu'un plan de livraison. Elle se distingue en cela du calendrier de fonctions que beaucoup d'entreprises appellent roadmap.

Le pattern Set-Based Design (conception par ensembles) traite la même incertitude au niveau des solutions. Choisir tôt une option et la développer à fond expose à tout reprendre quand une information nouvelle la contredit. Itérer améliore une idée, mais les auteurs, s'appuyant sur un article de Jakob Nielsen (1993), estiment que cela ne suffit pas à en faire naître une radicalement nouvelle. La solution, empruntée à Toyota, est de développer plusieurs options en parallèle en ne fixant que les contraintes critiques, de les comparer à mi-parcours et d'en éliminer. Les options restantes gagnent en précision à chaque étape, de l'esquisse au prototype. L'équipe de formation qui hésite entre un questionnaire en ligne, une étude de cas et une mise en situation filmée peut esquisser les trois en une journée chacune, les essayer avec deux stagiaires, puis n'en développer qu'une. Les auteurs signalent le coût humain d'une option écartée et le risque, dans un Sprint, de ne produire aucun incrément.

Fixed-Date PBI et Vacation PBI : ce qui s'impose au calendrier

Certains événements ne dépendent pas de l'équipe, comme la livraison d'un fournisseur ou l'entrée en vigueur d'une loi. Le pattern Fixed-Date PBI (élément à date fixe) demande au Product Owner de placer chaque élément bloqué par une telle dépendance à la position du Product Backlog qui correspond à la date où il deviendra réalisable, de noter cette date et de ranger au-dessous les éléments qui en dépendent. La position se vérifie souvent, puisque le reste de la liste bouge.

Le pattern Vacation PBI (élément « congés ») applique la même idée aux absences prévues. L'usage courant est d'abaisser la vélocité du Sprint concerné, puis de la rétablir. Les auteurs objectent que la vélocité est une mesure constatée et qu'une correction manuelle en fait un calcul dont personne ne se sent responsable. Ils proposent d'inscrire l'absence comme un élément du Product Backlog, estimé par les développeurs, car la production d'une équipe n'est pas proportionnelle à son effectif. Si l'équipe de formation, dont la vélocité moyenne est de 20 points, estime à 6 points l'absence de deux formateurs en août, il reste 14 points pour les modules de ce Sprint, et chacun voit pourquoi. Le livre reconnaît que chiffrer publiquement l'absence d'une personne est délicat, et que le pattern ne vaut pas pour les maladies imprévues.

Release Staging Layers : livrer par cercles

Les retours d'utilisateurs réels sont la matière première d'une équipe agile, mais livrer chaque Sprint à tout le marché coûte cher et comporte un risque. Les clients n'ont pas tous la même tolérance : certains veulent la nouveauté tôt, même imparfaite, d'autres exigent un produit éprouvé. Le pattern Release Staging Layers (paliers de mise en service) recommande de définir des publics successifs, des testeurs volontaires jusqu'au marché entier, et de livrer chaque Sprint à l'un d'eux au moins. Le livre cite les canaux de diffusion du navigateur Chrome. Un organisme de formation peut procéder de même : un groupe pilote reçoit chaque nouveau module, puis deux employeurs partenaires, puis le catalogue. Les auteurs précisent que chaque cercle reçoit un produit Done, et que l'existence d'un premier cercle ne doit pas servir d'excuse à une qualité moindre.

Change for Free et Money for Nothing : des contrats qui admettent le changement

Ces deux patterns concernent une équipe qui travaille pour un client dans le cadre d'un contrat à prix fixe. D'après le livre, Jeff Sutherland les a formulés lors d'une formation donnée aux Pays-Bas en 2006.

Change for Free (le changement gratuit) part du constat que des besoins apparaissent après la signature et que facturer chaque modification détruit la confiance. La solution est de s'engager par contrat sur les 80 % d'éléments les plus importants pour le client, et de lui permettre d'échanger une demande nouvelle contre un élément existant de valeur égale ou moindre pour lui, pourvu que le coût de réalisation ne soit pas supérieur. Le pattern suppose une équipe stable, expérimentée dans le domaine et capable de tout estimer dès le départ.

Money for Nothing (de l'argent pour rien) exploite l'ordre du Product Backlog. Les éléments de plus grande valeur étant livrés d'abord, chaque livraison apporte moins que la précédente, et il vient un moment où continuer coûte plus que cela ne rapporte. La solution est d'arrêter à ce moment. Le contrat donne au client le droit de s'arrêter à la fin d'un Sprint, moyennant une indemnité.

Value Stream Fork : scinder un produit devenu trop large

Un produit qui réussit s'étend et finit par servir des marchés dont les besoins et les rythmes divergent. Un Product Backlog unique doit alors entremêler plusieurs calendriers, l'équipe perd sa concentration et l'ajout d'équipes augmente le coût de coordination. Le pattern Value Stream Fork (bifurcation du flux de valeur) propose, quand au moins deux flux ont des cadences ou des contextes distincts, de scinder le produit en plusieurs produits ayant chacun son Product Backlog et son Product Owner. L'alternative, qui garde un backlog unique, est présentée dans l'article sur le passage à l'échelle.

Ce que dit le Guide Scrum 2020

• Le Guide ne mentionne ni plan de livraison, ni feuille de route, ni vélocité. Son horizon long est le Product Goal, vers lequel l'avancement est inspecté au moins une fois par mois.
• Il admet les pratiques de prévision, en rappelant que seul ce qui s'est déjà produit peut fonder une décision. Ce principe va dans le sens d'une fourchette calculée sur l'historique.
• L'édition 2017 demandait au Product Owner de suivre le travail restant au moins à chaque Sprint Review. L'édition 2020 a retiré ce passage.
• Les patterns de contrat, de congés et de paliers de mise en service sont propres au livre.

Limites et pièges

Une fourchette résiste mal à la transmission. Au fil des comptes rendus, la borne optimiste devient « la date ». Le livre lui-même glisse vers un langage de probabilités, en évoquant une livraison « à 80 % de chances » : la vélocité la plus basse de cinq Sprints n'est pourtant pas une probabilité, et les auteurs admettent ailleurs que trop de facteurs varient pour prétendre à une certitude statistique.

Le calcul suppose une équipe stable, des estimations cohérentes et un Product Backlog qui ne change guère. Aucune de ces conditions ne tient longtemps, d'où l'horizon de trois Sprints. Une vélocité scrutée par la direction a par ailleurs tendance à enfler, comme l'explique l'article sur l'estimation et la vélocité.

Les patterns de contrat reposent sur un exemple raconté par Sutherland dans son livre de 2014 : un client aurait payé 3,2 millions de dollars un produit chiffré à 10 millions, livré dix-sept mois plus tôt, pendant que la marge du prestataire passait de 15 % à 60 %. Aucune source indépendante n'est citée à l'appui. Ces clauses exigent en outre une confiance et une capacité d'estimation que peu de relations commerciales réunissent.

Plus généralement, ces dix patterns sont des pratiques tirées de l'expérience, et plusieurs sont notés par leurs auteurs comme des solutions parmi d'autres. L'article critique du corpus précise ce que cela implique.