Le flux de valeur

La Sprint Review

À la fin de chaque Sprint, la Scrum Team examine avec ses parties prenantes ce qui a été produit et décide de la suite. Le pattern Sprint Review d'A Scrum Book insiste sur un point que la pratique oublie souvent : on y fait essayer le produit et l'on en tire des décisions, on n'y déroule pas une présentation. Un second pattern, Product Wake, traite de la dernière revue possible, celle où l'on décide d'arrêter un produit.

Quarante minutes de diapositives

Une équipe développe un outil de prise de rendez-vous pour un groupe de centres de santé. Le dernier jour du Sprint, elle réunit le directeur, deux médecins et la responsable des secrétariats. Un développeur projette un diaporama qui énumère quatorze « fonctionnalités livrées », avec des captures d'écran. Le directeur demande si la date de mise en service tient toujours, on lui répond que oui, il remercie tout le monde et la salle se vide. Personne n'a touché à l'outil.

Trois semaines plus tard, une secrétaire découvre qu'elle ne peut pas réserver deux créneaux à la suite pour une consultation longue, ce qu'elle fait dix fois par jour sur son agenda papier. Elle connaissait ce besoin depuis toujours. Personne ne le lui avait demandé, et la réunion de fin de Sprint ne lui avait donné aucune occasion de le dire.

Cette réunion portait le nom de Sprint Review sans en remplir la fonction.

Sprint Review : clore le Sprint sur l'état réel du produit

Le pattern Sprint Review (revue de Sprint) se situe au moment où la phase de production du Sprint s'achève. Son problème est celui de la clôture : il faut établir où en est réellement le produit, et le fait d'avoir coché une liste de résultats attendus ne garantit ni qu'il a avancé autant que nécessaire, ni que l'équipe prendra ensuite la bonne direction.

Les auteurs décrivent plusieurs forces. Pendant le Sprint, les développeurs travaillent entre eux, à l'abri des interruptions. Cette protection a un revers, puisqu'une équipe laissée trop longtemps à ses propres impressions peut s'écarter de l'intention du produit. Un bon Product Owner se représente concrètement ce qu'il demande, mais personne ne prévoit tout dans un produit complexe : une réalisation concrète soulève presque toujours des questions qui n'étaient pas apparues en discutant. La communication entre le Product Owner et les développeurs perd de l'information, et chacun garde des hypothèses qu'il n'a pas pensé à formuler. Enfin, toute liste d'exigences est incomplète, car certains besoins restent inconnus de tous tant que le produit n'a pas été essayé.

De là vient l'argument central du pattern : pour savoir ce qui se passe vraiment, il faut examiner un produit qui fonctionne. Cocher des lignes du Sprint Backlog ne suffit pas.

La solution est de terminer la phase de production par un événement qui évalue l'état du produit et renseigne l'équipe sur les besoins des utilisateurs, les risques, les occasions à saisir, les problèmes et les dates d'achèvement probables. Les développeurs, le Product Owner et les parties prenantes qu'il a invitées y participent. Ils discutent de ce qui est prêt à être mis en service et de ce qui ne l'est pas, de ce que le Sprint a appris sur le produit, et des projets pour la suite. Le groupe cherche un accord, mais le Product Owner garde le dernier mot. Les auteurs lui conseillent d'inviter des utilisateurs importants et de solliciter leur avis.

Ce qui se passe pendant la revue

Le livre énumère des activités typiques :

• des utilisateurs manipulent eux-mêmes le produit ;
• le groupe discute de l'atteinte du Sprint Goal ;
• le Product Owner indique quels éléments sont Done et lesquels ne le sont pas, puis les développeurs montrent ce qui est Done ;
• le groupe examine la direction du produit et l'ordre du Product Backlog, en s'attachant à ce qu'il apprend ;
• il passe en revue des indicateurs de santé du produit, comme la vélocité, le niveau estimé de dette technique, l'état des défauts et l'avancement de la feuille de route ;
• il vérifie la suite donnée aux actions décidées à la revue précédente.

Plusieurs règles pratiques visent à empêcher la revue de tourner au spectacle. Les développeurs ne devraient pas passer plus d'une demi-heure environ à la préparer. Le produit est montré dans un environnement proche de celui de l'utilisateur, sans échafaudage provisoire destiné à le faire paraître meilleur qu'il n'est. Les auteurs résument cela par une boutade : pas de PowerPoint, sauf si votre produit est PowerPoint. Ils fixent la durée à trois heures au plus.

Ils demandent aussi au Product Owner d'accepter une position vulnérable, en écoutant si l'équipe approuve ses choix sur la direction du produit, la dette technique et la qualité. La revue porte sur le produit seulement. La manière dont l'équipe a travaillé relève de la Sprint Retrospective.

Ce que la revue peut apprendre, et ce qu'elle ne peut pas

Le pattern est lucide sur les limites de l'événement. Beaucoup de praticiens voient dans la Sprint Review le principal mécanisme de retour d'information de Scrum. Les auteurs nuancent. En trois heures, un Product Owner et quelques invités ne peuvent pas toujours juger si un incrément complexe répond au besoin. Un jugement plus sûr vient de l'usage du produit en situation réelle, sur une durée plus longue.

Ce que les participants remarquent bien, en revanche, ce sont les écarts entre ce que chacun croyait avoir convenu au Sprint Planning et ce qui a été livré. Selon les auteurs, ces écarts viennent moins souvent d'un changement d'avis du client que d'un défaut dans la manière de travailler : une question non posée, une hypothèse non vérifiée. L'une des fonctions principales de la revue est donc de repérer ces défauts et de les transmettre à la rétrospective. La dernière décision de l'exemple précédent en est un cas.

Le livre voit aussi dans la revue une occasion de fierté et parfois de fête. Il cite une entreprise finlandaise qui tenait de temps en temps la sienne dans un sauna, autour d'un bon repas.

Product Wake : savoir arrêter un produit

Chaque Sprint Review pose, au moins implicitement, la question de savoir si le produit mérite encore l'effort qu'on lui consacre. Le pattern Product Wake traite du jour où la réponse est non. Le mot wake désigne en anglais une veillée funèbre. Le contexte est celui d'un produit qui a rempli sa mission, dont l'utilité est passée ou dont il devient clair qu'il n'atteindra pas son but.

Le problème, selon les auteurs, est que mettre fin à un produit est souvent ce que les organisations font le plus mal. Ceux qui l'ont créé s'y sont attachés comme à un enfant. On peut toujours dépenser assez d'énergie pour maintenir un produit en vie, même quand ce qu'il apporte ne justifie plus cette dépense. Une fin est douloureuse parce qu'elle touche au gagne-pain de plusieurs personnes. S'acharner aboutit pourtant, le plus souvent, à une suite de réductions d'effectifs étalées dans le temps.

La solution est de donner au produit des funérailles dignes : clore le travail de façon nette, garder le processus transparent pour que les parties prenantes ne soient pas surprises, et tenir une rétrospective qui replace le produit dans son histoire et archive ce qu'il a appris à l'équipe.

Le livre précise que Scrum ne dit pas quand arrêter un produit. Il rappelle seulement que le Product Owner est responsable de la valeur et qu'il lui revient donc de trancher, avec l'accord le plus large possible. Le retour sur investissement est un critère, le sentiment et l'expérience en sont d'autres. Mieux vaut arrêter avant que la valeur du produit ne devienne durablement négative. Toutes les fins ne sont d'ailleurs pas des échecs : le logiciel écrit pour le festival d'une ville est retiré une fois le festival passé. L'équipe ne se disperse pas forcément, et le Product Owner comme le Scrum Master aident chacun à trouver sa place suivante.

Une médiathèque qui remplace son ancien service de réservation par courriel offre un exemple modeste. L'équipe fixe une date d'arrêt et l'annonce aux usagers deux mois avant. Elle consacre sa dernière séance à noter ce que ce service lui a appris sur les habitudes des lecteurs, puis archive les données utiles et supprime le reste.

Ce que dit le Guide Scrum 2020

• Le Guide donne pour but à la Sprint Review d'inspecter le résultat du Sprint et de déterminer les adaptations à venir. Il en fait une séance de travail et demande à la Scrum Team d'éviter de la limiter à une présentation, ce qui rejoint le pattern.
• La durée maximale est de quatre heures pour un Sprint d'un mois, et moins pour un Sprint plus court. Le livre indique trois heures : c'est un écart avec le Guide, dans son édition 2017 comme dans celle de 2020.
• Le Guide 2020 fait discuter l'avancement vers le Product Goal, l'objectif de produit introduit par cette édition. Le livre parle de vision et de feuille de route.
• L'édition 2017 détaillait le contenu de la revue, dont la démonstration par l'équipe de développement et l'examen du calendrier et du budget. L'édition 2020 a retiré cette liste.
• Dans le livre, le Product Owner évalue les éléments et décide de les accepter. Le Guide 2020 ne contient pas cette notion d'acceptation : un élément qui ne respecte pas la Definition of Done ne peut pas être présenté, et la revue n'est pas une étape obligée avant de livrer.
• Le Guide ne dit rien de la fin d'un produit. Il indique seulement que la Scrum Team doit atteindre ou abandonner un Product Goal avant d'en poursuivre un autre.

Limites et pièges

La dérive la plus courante est celle de la scène d'ouverture : une démonstration préparée avec soin, devant un public qui écoute. Elle rassure tout le monde et n'apprend rien à personne, car un invité poli ne contredit pas un diaporama. Faire manipuler le produit révèle davantage que demander un avis.

La dérive inverse transforme la revue en tribunal. Des responsables s'en servent pour relever ce qui n'a pas été fini et demander des comptes. Ron Jeffries a décrit cette situation dans son article « Dark Scrum » (2016), présenté dans l'article critique du corpus. Une équipe qui s'attend à être jugée prépare sa défense et montre le moins possible.

Une revue peut aussi rester sans effet. Si les parties prenantes ne viennent pas, l'équipe se présente son travail à elle-même. Si le Product Backlog sort inchangé de toutes les revues, soit le Product Owner prévoit remarquablement bien, soit les remarques ne sont pas prises en compte.

Sur l'efficacité de l'événement, il faut rester prudent. Dans une enquête publiée en 2023 auprès d'environ 2 000 équipes Scrum, Christiaan Verwijs et Daniel Russo trouvent que la qualité des Sprint Reviews fait partie des facteurs associés à l'efficacité déclarée des équipes. Il s'agit de réponses à un questionnaire, recueillies à un seul moment, qui ne permettent pas de conclure à une relation de cause à effet. Les recommandations du pattern, elles, viennent de l'expérience de ses auteurs.