La revue

Lors de la revue de sprint, l'équipe partage le résultat qu'elle a obtenu.

vendredi 25 février 2022 (révision : 21 février 2023 )

Sommaire

Le cycle symbolique du don étendu Demander - Donner - Recevoir - Rendre reflète bien ce que constitue la revue. À l’opposé du cycle diabolique Ignorer - Prendre - Refuser - Garder que subissent de façon dramatique bien des gens, des groupes et même des peuples en ce moment.

Ce dessin — qu’on trouve dans mon livre Scrum, avec la légende : “un moment de partage des résultats” — est un clin d’oeil à la permaculture.

Résumé

La revue sert à collecter le feedback des parties prenantes et prendre une décision sur le résultat obtenu en fin de sprint.

Ce rite est l’occasion de partager les réalisations de l’équipe avec le reste de l’organisation. La visibilité apportée et le feedback reçu permettent d’augmenter les chances que le produit soit un succès.

Points clés

Revue et pas simplement démo

La démonstration ne constitue qu’une partie de la revue de sprint.

Une invitation au feedback

La revue, c’est l’occasion de faire une boucle de feedback qui est au coeur de l’agilité.

La confiance

Le résultat essentiel de la revue est d’améliorer la confiance entre l’équipe et les parties prenantes.

Pourquoi, avec qui, quand, avec quoi, où ?

Un dessin vaut mieux qu’un long discours :

J’ajoute le pour quoi : pour apprendre. En effet la revue n’est pas une mise en service, c’est une occasion d’améliorer ses connaissances sur le produit ou service.

Comment se déroule une revue ?

Voici un enchaînement possible des activités de la revue :

Avant, l’équipe prépare tout ce qui est nécessaire pour que la démonstration se passe bien.
Au début de la revue publique, le Product Owner ouvre en statuant par rapport à l’objectif du sprint.
Ensuite, pour chaque story finie, l’équipe effectue une démonstration et collecte le feedback sollicité.
On profite de la présence des parties prenantes pour évaluer l’impact obtenu avec le produit et prendre une décision sur son avenir.

Antipatterns

Cinq antipatterns sont fréquents avec la revue de sprint.

Effet démo

Constat : le logiciel, c’est souple, des modifications peuvent être faites rapide- ment. À quelques minutes de la revue, l’équipe découvre un petit défaut, et se met dans l’idée le corriger vite fait.
Conséquence : une modification peut entraîner des régressions.
Comment faire mieux : pour ne pas risquer le fameux « effet démo », il est conseillé de ne pas toucher au code au dernier moment.

Démo du pas fini

Constat : quand c’est l’équipe qui présente, et en particulier quand c’est un développeur qui fait la démonstration, la tentation est forte de montrer tout le travail réalisé, même si ce n’est pas fini. Il commence par en parler puis finalement montre des morceaux non finis.
Conséquence : les parties prenantes sont troublées, elles perdent la confiance.
Comment faire mieux : il faut considérer la démonstration comme un résumé du travail du sprint, dans lequel on ne montre que les actions abouties, de la même façon qu’un résumé de match de rugby ne porte que sur les essais marqués.

Revue-spective

Constat : la discussion dérive sur la façon dont le sprint s’est déroulé, sur les tâches et sur les obstacles.
Conséquence : on ne reste pas concentré sur le produit.
Comment faire mieux : ce qui compte pour les parties prenantes, c’est le produit partiel avec les stories qu’il contient. La façon dont l’équipe travaille, ce n’est pas l’objet de la revue, mais de la rétrospective.

Démo privée

Constat : l’équipe oublie d’inviter les parties prenantes ; la revue se déroule uniquement avec l’équipe Scrum.
Conséquence : la revue perd de son intérêt.
Comment mieux faire : la revue de sprint est l’occasion de présenter les résultats, et il faut rechercher l’audience la plus large possible afin de développer des relations entre des gens qui ne se voient pas assez. Des invitations sont envoyées à toutes les parties prenantes, dont la liste doit être connue. Leur présence à la revue rend inutile la tenue d’autres réunions.

Les organisations qui fonctionnent d’habitude avec des comités (comité de pilotage, comité de suivi) devraient les supprimer pour ne conserver que les revues de sprint.

La revue permet d’éviter des démonstrations spécifiques pour des personnes importantes qui n’ont pas daigné se déplacer. Ce serait de la perte de temps que d’aller leur faire plus tard alors que la revue est prévue pour ça. Si quelqu’un d’important ne peut pas assister à la revue, ce n’est pas dramatique, la prochaine reviendra vite, au rythme des sprints.

Dans certaines organisations, on rechigne à inviter des personnes extérieures tant que le produit n’est pas suffisamment complet. Souvent par crainte qu’elles soient frustrées parce que le produit ne contient pas tout ce qu’elles attendent. Ce serait une erreur de se priver des bénéfices du feedback. Le mieux est de les sensibiliser à Scrum et de les inviter à la revue.

On peut leur rappeler qu’il s’agit d’un produit partiel et que les autres fonctions seront réalisées ultérieurement. Une bonne façon de procéder est de présenter le tableau kanban des fonctionnalités.

Démo sans feedback

Constat : pris par leur démo, les gens de l’équipe Scrum oublient de demander aux participants ce qu’ils en pensent.
Conséquence : pas d’enclenchement de feedback.
Comment mieux faire ? : un processus itératif fonctionne avec le feedback. La revue de sprint est l’endroit idéal pour le solliciter. Les personnes présentes peuvent intervenir pendant la revue et poser des questions lors de la démonstration. L’équipe y répond, soit en précisant un point mal compris, soit en expliquant que c’est déjà dans le backlog et sera fait plus tard, soit en ajoutant une nouvelle entrée dans le bac à sable.

Le feedback pendant la revue reste limité : les personnes ne manipulent pas elles- mêmes en général. C’est pourquoi il faut pousser à utiliser le résultat du sprint après la revue: pour cela, un environnement spécifique peut être mis à disposition des personnes qui souhaitent essayer le produit et faire ainsi un retour plus complet.

La revue à distance

Il est probable que, depuis la pandémie de la COVID-19, la plupart des revues de sprint des équipes Scrum se déroulent à distance.

Cependant de nombreuses revues se faisaient déjà avec des personnes à distance, en particulier les parties prenantes.

Le pattern Revue en trois parties est une variante d’organisation qui peut être utile dans ce contexte.