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

De Wiki Agile du @GroupeCESI
Aller à : navigation, rechercher

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


Traducteur : Fabrice Aimetti
Date : 30/08/2019


Traduction :

2019-08-27-why-you-should-consider-stopping-sprint-reviews-quote.png

Pour beaucoup d'équipes, la revue de sprint a fait son temps et il est temps d'arrêter de le 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 retours 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 retours 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 retour 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 propriétaire du produit plus tôt et sur une base continue. Il n'y a jamais eu de règle selon laquelle la rétroaction ne pouvait avoir lieu qu'à la fin du sprint dans une révision 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 enregistré, une compilation était déclenchée et des tests automatisés confirmaient que tout fonctionnait toujours.

Désormais, les grandes équipes délivrent ou déploient en permanence du code. Ils ne se contentent pas d'effectuer des tests automatisés après l'enregistrement, de nombreuses équipes se déploient après chaque enregistrement.

Cela change complètement la nature de la révision du 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 à 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 intervenants dans un examen : "Alors, que pensez-vous de 70 nouvelles choses que nous avons élaboré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 et du déploiement continus, il est trop tard pour obtenir les commentaires des parties prenantes dans le cadre d'un examen de fin d'impression - les utilisateurs utilisent déjà la fonctionnalité et les meilleurs commentaires viendront d'eux.

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

Si un seul examen de fin de course officiel n'est pas approprié pour les équipes qui publient fréquemment, que devraient-elles faire à la place ?

Ils devraient recevoir une rétroaction souvent et à petites doses. Dès qu'un élément de l'arriéré d'un produit est terminé, les membres de l'équipe devraient le montrer à un ou trois intervenants qui ont besoin de le voir avant qu'il ne soit publié. Souvent, ce pourrait être seulement le demandeur de la nouvelle fonctionnalité et le propriétaire du produit, s'il ne s'agit pas de la même personne.

Un ou deux des membres de l'équipe qui ont travaillé sur l'arriéré de produits organisent une démonstration rapide au demandeur. Ils montrent l'article, 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 produit en retard. Ils rencontrent l'intervenant ou les deux intervenants qui ont demandé cet article et peut-être le propriétaire du produit, font une démonstration rapide et offrent cette fonction.

Ce schéma peut se répéter aussi souvent que nécessaire. Parfois, bien sûr, ces mini-examens peuvent être regroupés : l'équipe peut montrer 2 ou 3 choses au propriétaire du produit en une seule fois, puis tout livrer s'ils sont approuvés. Et dans de nombreux cas, un niveau de confiance entre l'équipe de développement, le propriétaire du produit et les parties prenantes permet à l'équipe elle-même de prendre l'initiative d'offrir la fonctionnalité sans la mini-évaluation. Cela peut devenir une nécessité si l'équipe libère extrêmement rapidement.

Le risque de laisser une équipe prendre la décision n'est pas énorme. Beaucoup de ces changements sont isolés et ne sont que des dizaines de lignes de code. Si une équipe publie par erreur quelque chose que le propriétaire du produit n'approuve pas, la nouvelle fonctionnalité peut généralement être modifiée rapidement ou supprimé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 le sprint review plutôt que quelque chose comme la démo du sprint. Cette subtile différence de nom rappelle aux équipes qu'un sprint review est plus qu'une démo. La démo est l'activité centrale et le point focal de la plupart des revues, mais il se passe plus dans une bonne revue de sprint qu'une simple démo.

Un sprint review est l'occasion pour l'équipe et les parties prenantes de discuter des priorités et des plans pour le produit. De tels sujets sont courants :

Après avoir vu ce qui s'est terminé au sprint en cours, que pensez-vous qu'il faudrait faire au sprint suivant ? Y a-t-il des éléments de l'arriéré de produits qui devraient être augmentés ou diminués en priorité ? Y a-t-il des éléments de l'arriéré qui ne sont plus nécessaires et qui peuvent être éliminés ? Y a-t-il une opportunité de publier le travail du sprint en cours ? Si votre équipe livre continuellement et aborde ce genre de sujets dans ses revues de sprint, vous trouverez peut-être utile de tenir une revue traditionnelle de fin d'impression, même si les articles en retard de production individuels ont été pré-approuvés de la manière que je viens de décrire.

L'aspect éducatif des revues de sprints

Il y a aussi un aspect éducatif aux évaluations de sprint. Si une équipe livre continuellement et utilise des mini-examens ponctuels, il se peut que chaque élément soit vu par au moins un intervenant avant d'être livré. Cependant, avec cette approche, de nombreux intervenants ne seront pas au courant d'une grande partie du travail du sprint.

Par exemple, une équipe peut se déployer 50 fois pendant un sprint. On vous en a montré cinq avant qu'ils n'arrivent. On m'en a montré cinq autres. Mais aucun de nous n'a tout vu.

Cela donne au sprint review 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 arriérés de produits) mais peut aussi changer si les parties prenantes approuvent ou rejettent les mises en œuvre.

Ce qu'il faut faire

Je ne considère plus le sprint review comme un élément obligatoire de Scrum. Pour de nombreuses équipes, elle reste appropriée et aussi utile que jamais. Une équipe qui se déploie tous les trimestres, par exemple, est susceptible de bénéficier de l'examen de fin de tirage traditionnel, officiel et officiel, tel qu'il a été décrit et appliqué pendant des années.

D'autres équipes, cependant, en particulier celles qui se déploient ou livrent continuellement, trouvent l'examen traditionnel du sprint trop tard pour obtenir des commentaires utiles.

Pour ces équipes, l'obligation d'effectuer un sprint review est remplacée par une règle de "feed-back".

C'est à eux de décider quand et comment ils recevront la rétroaction, mais bon nombre d'entre eux choisissent de le faire sous forme d'évaluations ponctuelles et de mini-fonctions. Lorsqu'un élément est terminé, il est montré au petit groupe de personnes qui l'ont demandé ou qui en sont affectées. Dans certains cas, ces mini-examens peuvent avoir lieu plusieurs fois par jour.

Mais l'élimination totale de l'examen du sprint peut s'avérer trop lourde pour certaines équipes. C'est parce qu'une bonne critique a toujours été plus qu'une simple démonstration du produit. Ces équipes effectuent les mini-examens que j'ai décrits, mais elles les compléteront par un examen de fin de sprint, comme d'habitude, mais en mettant davantage l'accent sur l'aspect éducatif et le partage des connaissances de l'examen.

Qu'en pensez-vous ?

Avez-vous parfois l'impression qu'il est trop tard pour revoir le travail seulement à la fin du printemps ? Comment votre équipe s'est-elle adaptée en obtenant plus tôt les commentaires des utilisateurs et des intervenants ? Si votre équipe fournit ou déploie continuellement des services, êtes-vous passé à des examens ponctuels ? Veuillez nous faire part de vos réflexions dans les commentaires ci-dessous.