Pourquoi devriez-vous envisager d'arrêter les revues de sprint ?

Auteur : Mike Cohn
Source : Why you should consider stopping sprint reviews
Date : 08/2019

---

Traducteur : Fabrice Aimetti
Date : 30/08/2019

---

Traduction :



Pour beaucoup d'équipes, la revue de sprint a fait son temps et il est temps d'arrêter de la faire.

Blasphème ? Peut-être, mais écoutez-moi.

Le But de la Revue de Sprint

Le but de la revue de sprint est de permettre à l'équipe d'obtenir des feedbacks sur ce qu'elle a développé. Cette boucle de rétroaction peut donner lieu à de nouveaux éléments dans le backlog produit qui représentent soit de nouvelles idées de fonctionnalités, soit des ajustements sur ce qui a été récemment développé. Le product owner tient compte de cette rétroaction pour finaliser les priorités pour le sprint à venir.

Parce que son but est de recueillir des feedbacks sur ce qui a été développé, la revue se fait traditionnellement à la fin du sprint. Pour la plupart des équipes, cela se fait immédiatement avant la rétrospective.

Mais, organiser une revue de sprint à la fin du sprint intervient trop tard pour beaucoup d'équipes. Tout feedback recueilli pendant la revue arrive trop tard pour que l'équipe puisse l'utiliser dans le sprint en cours.

Les équipes le savent depuis des années. Dans presque tous les cours Certified Scrum Master dans lesquels j'enseigne, on me pose des questions comme :

• L'équipe peut-elle s'attribuer le mérite d'un élément du backlog produit terminé s'il y a une rétroaction qui nécessite un changement ?
• Et si c'était un petit changement ?
• Et si le changement était vraiment une amélioration ?

Depuis des années, la réponse standard est que les équipes doivent montrer leur travail au product owner au plus tôt et de manière continue. Il n'y a jamais eu de règle selon laquelle la rétroaction ne pouvait avoir lieu qu'à la fin du sprint lors d'une revue formelle.

Mais les temps ont changé. Il y a dix ans, de grandes équipes intégraient continuellement leur code - chaque fois que le code était reversé, un build était déclenché et des tests automatisés confirmaient que tout fonctionnait encore.

Désormais, les grandes équipes délivrent ou déploient en permanence du code. Elles ne se contentent pas d'effectuer des tests automatisés après avoir reversé le code, de nombreuses équipes déploient après chaque contribution.

Cela change complètement la nature de la revue de sprint.

Considérez la situation d'une équipe qui fournit de nouvelles fonctionnalités à la production en moyenne sept fois par jour. Pour une grande équipe de développement web, ce n'est pas inhabituel de nos jours.

Comment se déroulera la discussion lors de la revue de sprint à la fin d'un sprint de dix jours ? Au cours de cette période, l'équipe a livré 70 nouvelles choses (sept par jour pendant dix jours).

J'imagine que l'équipe a demandé aux parties prenantes dans une revue : "Alors, que pensez-vous des 70 nouvelles choses que nous avons développées ?"

Et les parties prenantes répondent : "Qui se soucie de ce que nous pensons ? Que pensent nos utilisateurs ? Ils ont déjà utilisé ces fonctionnalités."

Dans le monde de la livraison continue / du déploiement continu, il est trop tard pour obtenir les feedbacks des parties prenantes dans le cadre d'une revue de fin de sprint - les utilisateurs utilisent déjà la fonctionnalité et les meilleurs feedbacks viendront d'eux.

Qu'est-ce qui devrait remplacer la Revue pour ces équipes ?

Si une unique et officielle revue de fin de sprint n'est pas appropriée pour les équipes qui publient fréquemment, que devraient-elles faire à la place ?

Elles devraient recueillir des feedbacks souvent et à petites doses. Dès qu'un élément du backlog produit est terminé, les membres de l'équipe devraient le montrer à une ou trois parties prenantes qui ont besoin de le voir avant qu'il ne soit publié. Souvent, cela peut être uniquement le demandeur de la nouvelle fonctionnalité et le product owner, quand ne s'agit pas de la même personne.

Un ou deux des membres de l'équipe qui ont travaillé sur l'élément du backlog produit organisent une démonstration rapide au demandeur. Ils montrent l'élément, et s'il répond aux attentes du demandeur, il est livré, tout de suite.

Peut-être deux heures plus tard, d'autres membres de l'équipe ont terminé un autre élément du backlog produit. Ils rencontrent la ou les deux parties prenantes qui ont demandé cet élément et peut-être aussi le product owner, font une démonstration rapide et livrent cette fonctionnalité.

Ce schéma peut se répéter aussi souvent que nécessaire. Parfois, bien sûr, ces mini-revues à la volée peuvent être regroupées : l'équipe peut montrer 2 ou 3 choses au product owner en une seule fois, puis tout livrer si approuvées. Et dans de nombreux cas, le niveau de confiance entre l'équipe de développement, le product owner et les parties prenantes permet à l'équipe elle-même de prendre l'initiative d'offrir la fonctionnalité sans la mini-revue. Cela peut devenir une exigence si l'équipe sait livrer extrêmement rapidement.

Le risque à laisser une équipe prendre la décision n'est pas énorme. Beaucoup de ces changements sont isolés et ne représentent que des dizaines de lignes de code. Si une équipe publie par erreur quelque chose que le product owner n'approuve pas, la nouvelle fonctionnalité peut généralement être modifiée rapidement ou retirée.

La Revue de Sprint a-t-elle encore un rôle à jouer dans le cadre d'une livraison continue ?

Il y a une raison pour laquelle ça s'appelle la revue de sprint plutôt que quelque chose comme la démo du sprint. Cette subtile différence de nom rappelle aux équipes qu'une revue de sprint est plus qu'une démo. La démo est l'activité centrale et le point d'attention de la plupart des revues, mais il se passe davantage dans une bonne revue de sprint qu'une simple démo.

Une revue de sprint est l'occasion pour l'équipe et les parties prenantes de discuter des priorités et du calendrier pour le produit. De tels sujets sont courants :

• Après avoir vu ce qui a été terminé dans le sprint courant, que pensez-vous qu'il faudrait faire dans le sprint suivant ?
• Y a-t-il des éléments du backlog produit dont la priorité devrait être revue à la baisse ou à la hausse ?
• Y a-t-il des éléments du backlog qui ne sont plus nécessaires et qui peuvent être abandonnés ? Y a-t-il une opportunité de publier le travail du sprint en cours ?

Si votre équipe livre en continu et aborde ce genre de sujets lors de ses revues de sprint, vous trouverez peut-être utile de tenir une revue traditionnelle de fin de sprint, même si les éléments du backlog produit ont été individuellement pré-approuvés à la volée de la manière dont je viens de le décrire.

L'aspect éducatif des revues de sprints

Il y a aussi un aspect éducatif que l'on peut reconnaître aux revues de sprint. Si une équipe livre continuellement et utilise des mini-revues ponctuelles, il se peut que chaque élément soit vu par au moins une partie prenante avant d'être livré. Cependant, avec cette approche, de nombreuses parties prenantes seront ignorants d'une grande partie du travail du sprint.

Par exemple, une équipe déploie 50 fois durant le sprint. On vous en a montré cinq avant qu'elle n'aie fini. On m'en a montré cinq autres. Mais aucun de nous n'a tout vu.

Cela donne à la revue de sprint un aspect éducatif, car c'est le seul moment où tout le monde voit tout. Le fait de voir les fonctionnalités livrées dans le contexte d'un ensemble plus large de fonctionnalités peut générer de nouvelles idées (nouveaux éléments dans le backlog produit) mais peut aussi changer si les parties prenantes approuvent ou rejettent les implémentations.

Ce qu'il faut faire

Je ne considère plus la revue de sprint comme un élément obligatoire de Scrum. Pour de nombreuses équipes, elle reste appropriée et plus utile que jamais. Une équipe qui déploie tous les trimestres, par exemple, est susceptible de bénéficier de la revue de fin de sprint traditionnelle et officielle, tel qu'elle a été décrite et appliquée pendant des années.

D'autres équipes, cependant, en particulier celles qui déploient ou livrent en continu, trouvent que la revue traditionnelle du sprint intervient trop tard pour recueillir des feedbacks utiles.

Pour ces équipes, l'obligation d'effectuer une revue de sprint est remplacée par la règle "obtenir un feedback".

C'est à elles de décider quand et comment ils recueilleront ces feedbacks, mais bon nombre d'entre elles choisissent de le faire sous forme de revues ponctuelles de mini-fonctionnalités. Lorsqu'un élément est terminé, il est montré au petit groupe de personnes qui l'ont demandé ou qui sont impactées. Dans certains cas, ces mini-revues peuvent avoir lieu plusieurs fois par jour.

Mais se passer totalement de la revue de sprint peut s'avérer trop lourd pour certaines équipes. C'est parce qu'une bonne revue a toujours représenté plus qu'une simple démonstration du produit. Ces équipes effectuent les mini-revues que j'ai décrites, mais elles les compléteront par une revue de fin de sprint, comme d'habitude, mais en mettant davantage l'accent sur l'aspect éducatif et le partage des connaissances de la revue.

Qu'en pensez-vous ?

Avez-vous parfois l'impression qu'il est trop tard pour examiner le travail uniquement à la fin du sprint ? Comment votre équipe s'est-elle adaptée en obtenant plus tôt les feedbacks des utilisateurs et des parties prenantes ? Si votre équipe fournit ou déploie en continu, êtes-vous passé à des revues ponctuelles ? Veuillez me faire part de vos réflexions dans les commentaires ci-dessous.