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. Je vous invite à lire mes écrits plus récents sur Scrum. Claude Aubry


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 le processus 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 peut être animée par le ScrumMaster. Mais, notamment dans les environnements difficiles, il est préférable 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
  • le backlog de 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.

Erreurs à éviter

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

  • Les actions 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

A 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

Commentaires

1. Le jeudi 29 novembre 2007, 11:54 par calou

7ème sprint terminé, 3e rétrospective achevée : chaque réunion a été différente dans l'expression de chaque participant (de façon orale et avec les post-it + la pondération à la suite des regroupements en thèmes)

Chaque rétrospective est très forte en échanges: je pense que ces réunions sont indispensables même si elles mettent en doute l'organisationnel, la méthodologie elle-même, la mélée quotidienne !

Quelques post-it : (ne rigolez pas !!!)
- arrêter la réunion du matin
- réunion du matin trop tard (9h30)
- réunion du matin à faire sous timer (chronométrage ! ) [dure actuellement entre 15 et 25 min]
- faire la réunion tous les 2 jours
- faire une réunion par semaine
- ralentir le rythme des réunions
- estimation des taches incorrecte
- tests insuffisamment définis sur les tâches de conception, de programmation
- à confirmer : les réunions de revues avec les clients, l'aide sur les tâches annexes
- des oublis de tâches au tableau de sprint
- ...

De mon point de vue de manager, c'est un lieu et un moment d'échanges très important :
- c'est un instant, une pause, que l'on se donne dans le stress des jours, des projets, qui s'enchaînent durant les semaines du sprint,
- ça permet de recaler des dérives, des oublis par rapport à la démarche, de constater les efforts faits par chacun par rapport à la rétrospective précédente,
- C’est un échange indépendant des projets eux-mêmes qui concerne principalement l'organisationnel, les comportements, les méthodes...
- Une étape indispensable avant d'attaquer le sprint suivant...
- Comme souvent lorsque les personnes de l'équipe s'expriment, peu de points positifs : ça commence un petit peu, quelques post-its positifs => à augmenter !

Nous venons de terminer le backlog produit et la définition du backlog de sprint suivant : c'est vrai que les réunions en fin de sprint et en début sont nombreuses, prennent du temps, mais très fortes en échanges et de mon point de vue nécessaires. La définition du backlog de sprint est un engagement de chacun très fort et très contractuel.

Bon, je vous raconterais la prochaine !

Un ScrumMaster
Calou

2. Le dimanche 02 décembre 2007, 14:03 par claude aubry

Merci (Pas)Calou pour ce témoignage. Connaissant ton équipe, je suis très heureux de voir que les rétrospectives se poursuivent et surtout qu'elles sont utiles. J'espère que tu nous présenteras ton retour d'expérience au SigmaT de mars ?