[ÊTRE AGILE 3/4] A quoi sert vraiment le sprint review dans le développement d’un logiciel ?

Contexte

C’est dans un contexte de conduite de projet sous la méthode Agile que le sprint review a lieu. Elle participe activement à optimiser le management de projet, tant au niveau de la planification que de la communication entre les membres.

A quel moment

A la fin de chaque sprint, l’équipe projet organise une retrospective de sprint. Cette réunion a lieu à la fin d’une itération de sprint, c’est-à-dire à la fin de chaque cycle de développement du logiciel.

Objectif de la réunion

Cette réunion agit comme un levier d’amélioration et s’inscrit dans le principe d’amélioration continue dans lequel évolue l’équipe Scrum. Les principaux objectifs de cette réunion sont :

• Mettre à profit le vécu sur le sprint afin d’améliorer la prochaine itération,

• Gagner en efficacité lors du prochain sprint.

Qui fait quoi pendant le sprint review ?

Le rôle du coach : durant cette réunion, le coach influence mais n’impose pas. Partant du postulat que l’équipe dispose de toutes les ressources et capacités nécessaires pour remplir l’objectif visé, le coach doit seulement guider l’équipe afin qu’elle trouve elle-même les réponses aux questions qu’elle se pose durant le développement de l’application web. C’est dans cette posture que le coach doit animer la retrospective de sprint.

Comment faire un bon sprint review ?

Lors d’un bon sprint review, chaque membre de l’équipe se sent suffisamment à l’aise pour exprimer son point de vue.

Cette réunion répétitive qui a eu lieu à chaque fin de sprint doit être vivante et productive. Son déroulement peut être modifié si cela a un impact positif sur le projet.

Faire s’exprimer l’intelligence collective

Les points de vue de chacun doivent être exprimés. Chaque membre de l’équipe doit donner sa vision du projet. Cela permet d’avoir un prisme comple du projet, d’enrichir les choses, de faire progresser l’équipe et de trouver des solutions plus rapidement.

Démonstration de ce qui est « fini »

L’équipe devra préparer cette démonstration. Durant la réunion, seules les fonctionnalités finies et correspondant à des scénarios d’utilisateurs précis seront montrées sous la forme d’une démo. Les fonctionnalités non finalisées ne doivent pas être présentées lors de la revue de sprint.

Cette présentation ne doit pas être « formelle ».

Selon l’état d’avancement du produit : le product backlog du projet peut-être modifié.

La démonstration est censée susciter des réactions et améliorer la collaboration entre les membres de l’équipe du projet informatique.

Zéro jugement, zéro recherche de coupable

Il faut laisser chaque membre de l’équipe s’exprimer librement durant cette réunion. Chaque personne doit être bien consciente qu’en aucun cas elle ne sera jugée sur ce qu’elle pourrait dire. Dans l’éventualité ou un responsable hiérarchique serait présent durant cette réunion, il devra être briefé par l’animateur, afin que chaque participant se sente libre de s’exprimer y compris sur des sujets qui déplaire au responsable.

Si une personne accapare trop la parole, l’animateur, devra faire une pause et expliquer à cette personne qu’elle s’approprie trop la parole et qu’elle doit laisser les autres s’exprimer.

Laisser l’équipe s’auto-organiser et obtenir des améliorations qualitatives.

L’animateur ou animatrice ne doit pas céder à la tentation d’attribuer lui-même les actions d’amélioration aux membres de l’équipe. Il faut laisser l’équipe s’organiser elle-même et prendre en main les choses. Pour ce faire, privilégier la qualité et la pertinence des actions à la quantité. Ces actions doivent répondre à un certain nombre de critères connues sous l’acronyme SMART :

• Spécifique,

• Mesurable,

• Acceptable,

• Réalisable,

• Temporellement définie.

L’équipe doit s’approprier les actions. Demandez qui souhaiterait se charger de telle ou telle action, favorisez au maximum la prise d’engagement face aux autres membres de l’équipe.

Les actions doivent être transformées en tâches et rajoutées au tableau Kanban, c’est-à-dire au sprint backlog et doivent être réalisées durant le sprint au même titre que les autres tâches formant le product backlog. Ces tâches sont aussi estimées à l’instar des user stories du product backlog.

Diversifier les objectifs à atteindre

Définissez des objectifs pas trop ciblés à atteindre. Bien évidemment, les objectifs peuvent varier d’une rétrospective à une autre. Voici quelques exemples d’objectifs que l’équipe projet pourrait se fixer :

• Améliorer nos relations avec le service commercial,

• Comprendre les raisons pour lesquelles les tickets du précédent sprint n’ont pas tous été développés,

• Comprendre les raisons pour lesquelles la qualité est en baisse sur les fonctionnalités finies,

• Etc.

Pensez à changer d’animateur ou d’animatrice : du renouveau peut créer une nouvelle émulation et impacter de manière positive les résultats. Donc, si une personne de l’équipe se porte volontaire pour animer la prochaine review de sprint, donnez lui quelques conseils et laissez-la se lancer.

Mettre en place un code conduite

Mettez en place les commandements au bon déroulement d’un sprint review. Ne pas édicter trop de règles (entre 6 et 7 maximum), il faut que ce soit simple à retenir. Exemples :

• Mettre son portable en mode avion,

• Ne pas utiliser son ordinateur portable,

• Chaque membre de l’équipe parle à tout de rôle,

• On a le droit de « passer son tour » de parole durant un tour de table,

• etc.

Le must de la retrospective

Avec l’équipe, définissez ensemble ce que vous souhaitez garder et ce que vous ne souhaitez pas garder dans la manière dont se déroule la retrospective. Comment améliorer les retrospectives ? Rentrer dans un processus d’amélioration des sprints review en impliquant tous les membres de l’équipe ne pourra qu’avoir des effets positifs sur les résultats, la rentabilité et la gestion de projet.

Pour aller plus loin

Les retrospectives de sprint peuvent complètement servir à définir les valeurs et la culture de votre organisation. Etant une réunion informelle, où chacun s’exprime librement : cette retrospective peut être le moment de recherches collectives d’actions et d’idées.

Ces valeurs peuvent bien évidemment toucher l’ensemble de l’organisation et pas seulement l’équipe projet. Ce type d’action s’intègre complètement dans la démarche d’une entreprise qui souhaite aller vers plus d’agilité.

Ce qu’il ne faut pas faire

• La préparation de la démonstration du produit qui sera effectuée au sprint review ne doit pas durer plus d’une heure,

• Modifier le code à la dernière minute juste avant la réunion,

• Faire une présentation de fonctionnalités non « finies »,

• Faire une démonstration de fonctionnalités qui ne correspondent à aucun scénario d’utilisateur,

• Rendre cette réunion trop formelle,

• Montrer des scénarios d’utilisateurs finaux inachevés,

• La réunion ne doit pas excéder 2 heures, en général elle est d’une durée de 1h.

Tenez-vous au courant de l’ensemble des actus à propos de l’offshore informatique.