La rétrospective de sprint

De l'amélioration de processus, concrète (et sans s'encombrer de CMM-I !)

Ok, vous arrivez sur cette page. Sachez qu’elle date de 2007. L’essentiel de l’article reste valable aujourd’hui. Cependant j’ai apporté de légères inflexions à la façon de mener une rétrospective. Je vous invite à lire mes écrits plus récents sur Scrum.

Dans la série les réunions d’un projet agile, voici la rétrospective, présentée avec le vocabulaire de Scrum.

Le but de la réunion est d’améliorer la façon de travailler pour le prochain sprint[1].

Participants

Toute l’équipe Scrum participe à la réunion.

La rétrospective a lieu juste après la revue de sprint et les intervenants qui sont venus y assister peuvent rester pour la rétrospective, à titre d’observateurs. Cependant, la confiance est nécessaire pour le succès d’une rétrospective et la présence de certaines personnes peut être un obstacle à son instauration.

La réunion est généralement animée par le ScrumMaster. Cependant, dans les environnements difficiles ou si l’équipe est débutante, il est envisageable que ce soit une personne extérieure à l’équipe qui joue le rôle de facilitateur de cette réunion.

Produit en entrée

  • le plan d’actions de la rétrospective précédente
  • la liste des problèmes

Etapes

  • Créer un environnement propice à l’expression

Pour bien rester sur l’objectif qui est de s’améliorer et pas de juger, le principe de base d’une rétrospective est rappelé aux participants :

Indépendamment de ce que nous allons découvrir aujourd’hui, nous comprenons et nous croyons vraiment que chacun a fait de son mieux, en fonction de ses connaissances, de ses compétences et de ses capacités, des ressources disponibles et de la situation courante.

S’il y a des doutes sur la confiance, il est préférable de demander à chacun, à bulletin secret, de dire s’il se sent en capacité de s’exprimer librement.

  • Collecter les informations relatives au processus

Avant de chercher à améliorer les pratiques, il convient de collecter le ressenti des participants sur ce qui s’est passé pendant le sprint qui s’achève. L’approche basique est de demander à chaque participant ce qui a bien marché et ce qui a mal marché. Cependant le risque avec cette approche un peu brutale est de ne pas collecter beaucoup d’informations.

Il existe de nombreuses techniques, sous forme d’ateliers[2], permettant d’obtenir un meilleur résultat : l’objectif est d’aboutir à lister les événements qui sont intervenus en les classant selon qu’ils ont eu un impact positif ou négatif sur le projet. On peut s’appuyer sur le backlog de problèmes, s’il existe.

  • Consolider

    Les événements sont regroupés en catégories, de façon à en obtenir entre 5 et 10. Ce travail sera fait de préférence de façon collective, ce qui est facilité par l’utilisation de notes collantes pour l’identification des événements à l’étape précédente.

  • Définir les priorités

    Il s’agit de définir sur quelle catégorie va porter l’effort d’amélioration. Il est préférable de n’en sélectionner qu’une seule. La technique de sélection doit permettre la participation de toute l’équipe, avec par exemple un système de votes.

  • Planifier des actions d’amélioration

    Pour la catégorie choisie pour l’amélioration, il s’agit de définir les actions concrètes qui vont être menées, en ayant un responsable de l’application de chacune.

Produit en sortie

  • le plan d’actions pour le sprint qui va démarrer. Des actions peuvent être consignées dans le backlog de sprint.

Considérations importantes

La réunion est limitée dans le temps. La première faite avec une équipe est toujours un peu plus longue. Ensuite la durée peut être limitée à une heure quinze.

Erreurs à éviter

Sur le plan d’actions de la rétrospective précédente :

  • Les actions décidées n’ont pas été faites

Pendant la réunion :

  • Peu d’informations sont collectées
  • Des personnes ne s’expriment pas du tout
  • Une seule personne parle tout le temps

À la fin de la réunion :

  • Le plan d’actions n’existe pas ou ne précise pas concrètement ce qui va être fait
  • Le plan d’actions porte sur de trop nombreux axes d’amélioration
  • Il n’y a pas de responsable pour les actions définies

L’erreur la plus grave est d’arrêter de faire des rétrospectives. Le Manifeste Agile dit :

A intervalles réguliers, l’équipe réfléchit à comment devenir plus efficace, puis adapte et ajuste son comportement en conséquence.

Ne pas utiliser cette possibilité de feedback sur la façon de travailler, ce serait passer à côté d’un des bénéfices majeurs des méthodes agiles.

Notes

[1] qui, en principe, va commencer juste après la réunion, ou le lendemain

[2] comme celui décrit dans ce billet

Voir aussi :