Agile smells – Sprint review

Suite de la série d’articles consacrée aux Agile smells, je vous propose, au travers de situations réellement vécues, de faire un tour d’horizon des dérives, des fausses bonnes idées ou simplement des phrases prononcées qui peuvent vous amener à vous dire que quelque chose sent mauvais. Aujourd’hui, parlons de la sprint review…

Si vous avez manqué un des épisodes de la série des Agile smells, vous pouvez les retrouver ici :

• Agile smells – Management visuel
• Agile smells – Sprint planning
• Agile smells – Sprint daily stand-up meeting
• Agile smells – Sprint retrospective
• Agile smells – Backlog et user stories
• Agile smells – Pratiques de développement et de test
• Agile smells – Rôles et motivation

« Plus c’est long, plus c’est long… »

La situation

Quatre feature teams se retrouvent pendant plus de deux heures pour présenter ce qu’il s’est passé durant l’itération. Après une introduction par le chef de projet pour évoquer l’actualité sur le projet, chaque équipe passe l’une après l’autre et déroule un plan quasi identique :

• Présentation des chiffres clés par le Scrum Master (vélocité avec historique, nombre de bugs traités, etc.) au travers de slides.
• Explication par les Product Owner des fonctionnalités prévues pour l’itération au travers de slides.
• Démonstration de ces fonctionnalités par les développeurs directement sur l’application.
• Présentation des chiffres clés par l’équipe de recette (nombre de bugs ouverts et corrigés en recette et production, etc.) au travers de slides.
• Présentation des sujets de la prochaines itération par les Product Owner au travers de slides.

Pourquoi ça sent mauvais ?

Le temps passé sur des slides est extrêmement conséquent. La revue de sprint doit avoir un seul objectif : montrer l’incrément de produit qui vient d’être réalisé et engager une discussion autour de cela afin d’avoir un premier retour de la part des utilisateurs.

Forcément, passer une heure à regarder des slides n’est pas ce qu’il y a de plus intéressant pour les équipes et les personnes finiront par percevoir cette cérémonie comme une contrainte. Des comportements typiques vont alors apparaître comme l’utilisation d’ordinateurs ou téléphones portables afin de digérer plus facilement la longueur de la réunion.

De plus, les utilisateurs finaux ne sont pas intéressés par les métriques internes aux équipes même si cela part d’une bonne intention, à savoir le soucis de transparence. Ils sont là pour voir le produit qui doit changer leur quotidien.

Concrètement on fait quoi ?

L’objectif à atteindre pour une revue de sprint est simple : une heure maximum sans aucun slide. Cela demande simplement :

• Une salle adaptée

Difficile de suivre une présentation si des personnes sont debout ou si la visualisation se fait sur un écran d’ordinateur au bord d’un bureau. Une salle suffisamment grande et un vidéo projecteur sont indispensables pour le confort des participants.

• Une histoire utilisateur

Pour montrer les nouvelles fonctionnalités, quoi de mieux que créer des histoires utilisateurs ? Après tout, c’est sur cette base qu’ont été effectués les développements non ? Si vous froncez les sourcils, il est peut être temps de vous tourner vers la spécification par l’exemple. Dans tous les cas, nul besoin de réaliser un jeu d’acteur studio, une simple narration peut être suffisante.

• Une préparation

Pour être sûr de la qualité ainsi que de la durée de la démonstration, il faut la préparer. Cela passe par une session la veille de la revue de sprint où l’équipe se réunit pour jouer la démonstration en condition réelle. Cela permet de valider les discours, de se synchroniser entre ceux qui prennent la parole et la personne responsable du clavier, et d’ajuster les temps de parole pour ne pas dépasser une heure au total.

• Une exception qui confirme la règle, mais seulement une

Enfin, si vous souhaitez absolument mettre un slide dans votre présentation, le seul qui puisse avoir une utilité est le planning de release afin de montrer à tout le monde où se trouve le projet dans sa globalité, et peut être faire quelques ajustements.

« Désolé cette story n’est pas validée »

La situation

Le projet est constitué de cinq feature teams. Chaque équipe valide les user stories durant l’itération avec un Proxy Product Owner dédié. Lors de la revue de sprint, les équipes présentent les unes après les autres les fonctionnalités pré-validées au Product Owner et ce dernier les valide à son tour. Les fonctionnalités non validées sont reportées sur l’itération suivante.

Pourquoi ça sent mauvais ?

Ici deux principaux problèmes peuvent être identifiés :

• La revue de sprint sert de validation finale

Si la validation des stories se fait une fois l’itération terminée, il est impossible pour l’équipe d’effectuer les correctifs. Le premier symptôme va donc être la vélocité de l’équipe qui sera impossible à anticiper. De plus, cette pratique rend obsolète la notion d’engagement de l’équipe en début d’itération car on ne lui donne pas tous les moyens de les tenir. Il devient alors difficile d’obtenir une forte motivation sans cette part d’autonomie.

• Il y a une différence entre la compréhension des PPO et du PO

Si la validation du Proxy Product Owner ne vaut pas celle du Product Owner, soit il manque un niveau de délégation et de confiance entre eux, soit la maitrise du produit par le PPO n’est pas assez importante. Généralement, ces deux cas sont souvent liés.

Concrètement on fait quoi ?

Peu importe l’organisation de l’équipe, la revue de sprint ne doit pas servir de validation. Son but est de présenter aux utilisateurs l’incrément de produit et avoir les premiers retours pour éventuellement alimenter le backlog de nouveaux éléments.

Dans une organisation avec Proxy Product Owner, deux règles simples à suivre :

• Si le PPO maîtrise le produit, le PO doit faire une confiance aveugle et ne pas remettre en cause une fonctionnalité validée lors de la revue de sprint. S’il y a des retours, ils peuvent être pris en compte via une nouvelle user story ou via la création de bug.
• Si le PPO ne maîtrise pas le produit, le PO doit participer en amont à la validation des fonctionnalités en binôme avec le PPO lors de l’itération. Cette phase d’apprentissage permettra à terme au PPO d’obtenir une autonomie suffisante. Evidemment, la participation du PO plus en amont est fortement recommandée, lors de la définition de la user story notamment, par binômage ou simple relecture.

Beaucoup de remarques des utilisateurs

La situation

Lors de la revue de sprint, les utilisateurs s’expriment souvent pour signaler des choses qui leur déplaisent.

Pourquoi ça sent mauvais ?

Certaines personnes ont besoin de voir concrètement le produit pour prendre conscience de ce qui leur déplait. Si le produit répond à leur besoin initial mais que leur réflexion a évolué, la revue de sprint a rempli son rôle et les remarques des utilisateurs ne doivent pas être prises comme un problème mais comme une opportunité.

En revanche, si les remarques pointent des éléments qui n’étaient pas attendus ou qui donnent l’impression d’une déception, alors il s’est passé quelque chose entre le moment où l’utilisateur a exprimé son besoin et le moment où ce dernier a été implémenté. Ce genre de situation arrive fréquemment lorsque, face à un besoin utilisateur incomplet, l’équipe va émettre des hypothèses. Faire des hypothèses n’est pas un problème en soi, ne pas les valider au plus tôt en est un.

Concrètement on fait quoi ?

Une étape essentielle lors de la définition du besoin est de faire en sorte que tout le monde parle le même langage. Un atelier du type Three Amigos réunissant métier, développeur et testeur, permet une discussion centrée sur le besoin et agrémentée d’exemples concrets (repris pour les tests ensuite), qui ne laisse plus de place aux hypothèses.

De plus, la création de prototypes ou de maquettes, même dans des versions très basiques, permet généralement de valider définitivement le besoin.

« Et ils sont où ? Et ils sont où les utilisateurs ? lala lala la… »

La situation

La revue de sprint est effectuée avec les développeurs, les testeurs, les Product Owner et parfois certaines personnes d’un autre service. Aucun utilisateur final n’est présent.

Pourquoi ça sent mauvais ?

Si les utilisateurs ne découvrent leur produit que lors de la mise en production, les risques sont multiples :

• Dans le cas où ils n’ont pas non plus été consultés en amont du projet, l’outil est vécu comme étant imposé. Il ne répondra pas de manière quasi certaine aux réels besoins et sera entièrement rejeté même si certaines fonctionnalités étaient utiles. L’argent investi n’aura donc servi à rien.
• Si les utilisateurs avaient bien été contactés lors du recueil du besoin, le risque est de faire face à une déception de leur part lorsqu’ils vont découvrir un produit différent de ce qu’ils avaient imaginé. La moindre petite coquille devenant rapidement un prétexte pour critiquer le produit et le faire savoir autour de soi.

Concrètement on fait quoi ?

Impliquer les utilisateurs tout au long des développements est le meilleur moyen d’obtenir leur adhésion ainsi qu’un produit qui réponde précisément à leur besoin. Les inviter à la revue de sprint permet d’avoir un retour immédiat voire même, dans un cas extrême, de soulever un risque qui repousserait une mise en production. D’un point de vue utilisateur, il est préférable de décaler une mise en production suite à leur remarque, plutôt que de livrer un correctif trois jours après qu’ils aient été bloqués dans leur travail quotidien.

Deux situations sont à distinguer :

• Produit interne à une entreprise

Les personnes ciblées par le produit sont clairement définies. Par conséquent, il n’existe aucune excuse pour ne pas les inviter à participer de manière régulière à la revue de sprint car il s’agit de participer à la création de l’outil qui va améliorer (voire révolutionner) leur travail. Si vraiment leur agenda est surchargé, un compromis peut être trouvé en ne les invitant qu’une itération sur deux, au delà, la boucle d’apprentissage devient trop longue pour être vraiment efficace.

• Produit à destination du grand public

La revue de sprint se passe généralement avec les différentes parties prenantes, ces personnes qui participent au projet sans pour autant faire partie de l’équipe à proprement parler. L’idée ici étant d’aligner tout le monde sur le produit. Concernant les utilisateurs finaux, il est important d’arriver à organiser des ateliers avec eux sur un panel très restreint après chaque itération. Il s’agit ici d’effectuer des tests qualitatifs permettant de recueillir les premiers ressentis très rapidement après les développements. Dans un second temps, pour chaque release par exemple, l’organisation d’ateliers sur des panels plus importants d’utilisateurs permettra de réaliser des tests en plus grande quantité permettant ainsi de valider que le produit va dans la bonne direction.

Dans tous les cas, il est toujours important d’avoir l’équipe de développement (ou des représentants) dans ce genre d’atelier afin de maintenir la vision utilisateur au centre de l’équipe et donner davantage de sens aux développements.

Conclusion

Au travers de quatre situations, nous avons découvert comment la sprint review pouvait révéler des pratiques contre productives, mais également, comment il pouvait être une aide d’une grande efficacité pour améliorer de nombreux aspects de la vie d’une équipe. Ne jetez pas votre désodorisant tout de suite, nous revenons bientôt avec de nouveaux agile smells dédiés cette fois-ci à la sprint retrospective.