Une bouffée d’air avec la rétrospective

08 juillet 2010

Avez-vous déjà remarqué en revenant dans une pièce, que l’air ne sentait pas si bon? Vous y étiez pourtant depuis des heures et n’aviez rien remarqué. Vous étiez occupés. C’est après être sorti de la salle pour prendre l’air que cela vous saute au nez.

La rétrospective en Scrum s’apparente à cette bouffée d’air frais : il faut sortir pour mieux voir et découvrir qu’il est décidément temps d’ouvrir la fenêtre.

L’objectif

L’idée de la rétrospective est de se donner un moment pour regarder derrière soi, faire un point. Cette réunion à la fin de chaque sprint est le prix de l’amélioration continue. Sans elle, nous finissons par nous habituer à l’air renfermé, nous nous y sentons même plutôt bien. Nous ne voyons généralement pas les eèmes. Et même en les voyant, nous n’avons pas le temps de les traiter.

Réunir l’équipe régulièrement permet de réfléchir aux facteurs de réussite et d’échec, puis de générer des idées pour les perpétuer ou les supprimer. Certaines idées sélectionnées sont ensuite déclinées en actions. C’est ainsi que nous transformons de l’output en input, des éléments produits en matière à alimenter la production et que nous progressons finalement.

Pour faire un point sereinement et rester constructif, il est indispensable de construire un cadre rassurant pour l’équipe. L’établissement de règles permet d’éviter que la rétrospective ne tourne au règlement de comptes.

Les règles

La présomption de bonne volonté

Il s’agit de la directive première de toute rétrospective. Chacun a fait de son mieux, dans le temps qui lui était imparti avec les informations dont il disposait. La version originale est plus longue :

Indépendamment de ce que nous découvrons, nous comprenons et nous croyons sincèrement que chacun a fait du mieux qu’il pouvait, compte tenu de ce qu’il savait à l’époque, de ses compétences et de ses prérogatives, des ressources disponibles et de la situation du moment (Traduction de Fabrice Aimetti).

L’expression en son nom

La réunion ne peut pas être constructive si le blâme nous menace du coin de la porte, que ce soit envers des personnes présentes (elles se braquent) ou absentes (n’étant pas présentes, elles ne sont pas dans le périmètre d’action possibles). Afin d’éviter tout malentendu ou blâme implicite (il ne m’a rien dit”,”tu avais dit que tu t’en occuperais”), l’usage du “je” est de mise (je n’étais pas au courant, comment éviter cela à l’avenir?”, “je croyais que tu t’en occupais”). Cela permet d’éviter les mauvaises interprétations vu que l’on parle en notre nom et d’éviter de pointer les autres du doigts : nous restons sur du factuel. Il rend aussi aux autres la responsabilité de trouver des solutions.

L’écoute

Pour pouvoir s’écouter, il faut veiller à ce que plusieurs personnes ne parlent pas en même temps, qu’il n’y ait pas de conversations privées.

Application des règles

La première règle est la véritable constante de toutes les rétrospectives. L’écoute et l’expression en son nom ne sont pas toujours à proprement dit des règles explicites. Chaque équipe peut en rajouter d’autres comme lever la main pour prendre la parole, ne pas faire de blagues ou au contraire, en supprimer.

Rappeler régulièrement les règles établies n’est pas un luxe, pour deux raisons : d’une part, nous avons la mémoire courte; d’autre part, s’exprimer dans cet esprit requiert beaucoup de discipline et de pratique. Il faut du temps. Personnellement, j’aurais tendance à les rappeler à chaque fois pour mettre à l’aise les personnes présentes, que ce soit une sorte de rituel. En faire une habitude nous empêche de les oublier quand une nouvelle personne intègre l’équipe.

Un animateur veillera à ce que ces règles soient respectées pendant la réunion. Il vaut mieux qu’il soit extérieur au projet : un scrum master dedié, un scrum master d’une autre équipe. A défaut, il vaut mieux que ce soit la personne de l’équipe la moins impliquée émotionnellement (ce qui ne veut pas dire que le projet ne l’intéresse pas), pour qui “tout s’est bien passée” pour qu’on puisse la croire relativement neutre. De plus, en tant qu’animateur, il sera moins amené à s’exprimer que les autres. Son energie sera concentrée sur l’encouragement de la libre expression et de la recherche de solutions par l’équipe.

Le déroulement

La rétrospective suit les étapes suivantes :

  1. Planter le décor
  2. Collecter des informations
  3. Générer des réflexions
  4. Planifier des actions
  5. Clore la rétrospective

1. Planter le décor

Un rituel peut aider à lancer la réunion tranquillement, en remerciant la présence des interlocuteurs et/ou rappelant les règles de la réunion. Cela permet aussi, en rassurant, de créer un environnement propice à l’expression.

Vote de confiance

Afin de vérifier que les participants sont prêts à s’exprimer, nous pouvons procéder à un vote de confiance anonyme. Chacun évalue sur un post-it sa liberté de s’exprimer, son aise avec les personnes présentes.

Les notes vont de 1 à 5. Des exemples de situations peuvent aider les votants à se situer sur l’échelle, comme :

“Vous dites oui à tout… car à quoi bon ?” => 1

“Vous n’aimez pas trop être jugés, alors avez tendance à laisser faire, sauf pour les choses vraiment vraiment importantes quand on vous le demande” => 2

“Vous dites généralement ce que vous avez à dire et l’ambiance de l’équipe est correcte” => 3

“Vous n’hésitez pas à vous exprimez et êtes tout à fait à l’aise avec les personnes présentes.” => 4

“Vous êtes tellement à l’aise dans l’équipe que c’est bière tous les soirs avec eux. D’ailleurs, vous allez pique-niquez ensemble ce week end avec votre famille.” => 5

En fonction des résultats, le Scrum Master peut se demander s’il faut maintenir la réunion ou non. Si des gens ne s’expriment pas, elle constitue une perte de temps. Quelques actions immédiates peuvent aider à monter le niveau de confiance : faire sortir un chef, aller prendre un café, rajouter des règles supplémentaires (“Les blagues ne sont pas autorisées”). Si les notes ne s’améliorent pas au deuxième tour, il vaut mieux la reporter et prendre le temps d’investiguer.

Une alternative provisoire peut-être de récolter les données de l’itération par e-mail uniquement : seul l’animateur en a connaissance. Il aborde ensuite ces points pendant la rétrospective.

Pour éviter ce genre de situations, l’animateur peut enquêter au préalable auprès de chacun des participants sur le ressenti de l’itération. Certaines mesures peuvent ainsi être prises en amont : ne pas inviter certaines personnes, organiser un one to one, changer d’animateur.

Ces interviews préalables permettent également à l’animateur de faire une rétrospective sur mesure en choisissant des exercices adéquats.

Explorateur Shopper Vacancier Prisonnier (ESVP)

Nous pouvons aussi demander aux participants d’indiquer anonymement leur état d’esprit par rapport à la réunion, en écrivant E, S, V ou P sur les post-its.

Il s’agit d’un explorateur (E) si, tel Indiana Jones, il vient en rétrospective à la recherche de trésors merveilleux.

Un shopper (S) va à la rétrospective comme il fait du shopping : il regarde, sans intention particulière mais ne serait pas étonné de tomber sur de bonnes affaires.

Un vacancier (V) voit la réunion de rétrospective comme des vacances, un évènement qui le sort de son quotidien.

Un prisonnier (P) est à la réunion parce qu’il n’a pas le choix . Il n’en voit vraiment pas l’intérêt.

2. Collecter des informations

Cette étape permet de récolter des informations sur le sprint.

Note d’itération

En faisant un tour de table, chacun donne une note sur cinq de l’itération, telle qu’il l’a vécu en disant ce qui a fonctionné et ce qui n’a pas marché. Dans l’optique d’amélioration continue, l’intervenant dit ce qu’il aurait fallu pour atteindre une note de 5, comme dans le perfection game.

Keep Drop Start

Il s’agit de l’exercice le plus courant, il est simple et complet. Les participants réfléchissent aux points qu’ils voudraient évoquer, en les classant dans une catégorie : Keep, Drop, Start ou les Questions. Un post-it représente une idée.

Keep : ce qui s’est bien passé et qu’il faut encourager;

Drop : ce qui s’est mal passé et que l’on ne veut plus voir répéter;

Start : les actions à entreprendre suite aux keeps et drops identifiés.

Questions : les points en suspens, les interrogations de l’équipe;

Ces points sont ensuite affichés sur le tableau, à tour de rôle ou tous en même temps. L’avantage de le faire à tour de rôle est que la durée de la réunion est plus facilement maitrisée. On peut décider à n’importe quel moment d’arrêter de tourner, tout le monde aura au moins parlé une fois. Il y a donc intérêt à évoquer en premier les points qui nous paraissent les plus importants.

Si l’animateur choisit de retranscrire les post-its sur le tableau, il faut faire attention à ce que la phrase résumé reflète bien l’idée de son auteur, et lui demandant confirmation. Les intérêts de la retranscription sont que :

  • nous sommes surs que tout le monde comprend la même chose après reformulation de l’animateur;
  • l’idée est plus lisible sur le tableau (grâce à la reformulation, l’idée tient sur un post-it et il y a moins de problème avec les écritures de chacun);
  • moins de papier gâché (on peut écrire nos idées sur du papier brouillon plutôt que sur des post-its)

L’inconvénient de cette approche est qu’elle prend un peu plus de temps.

La case Start a tendance à être plus alimentée pendant la discussion, au fur et à mesure que les Keep et Drop sont présentés.

Cet exercice comporte de nombreuses variantes : Mad Sad Glad, roblem, etc. L’exercice du Salomo peut sembler plus constructif pour certains.

Timeline

Une ligne temporelle représentant l’itération est tracée sur un mur. Chacun réfléchit aux évenements qui l’ont marqué et les note sur des post-its. Un code couleur peut être utilisé pour indiquer le thème : technique, relation d’équipe et organisation par exemple.

Une fois que tout le monde a réfléchi, les post-its sont positionnés sur le graphique : plus il est haut, plus l’évènement a été perçu positivement. Le positionnement peut se faire à tour de rôle, ce qui permet de tracer une courbe par personne, ou alors tout le monde en même temps pour gagner du temps et avoir une courbe collective. La contrepartie est que le participant n’a pas vraiment l’occasion d’expliquer ce qu’il a écrit sur le post-its.

Nous pouvons ainsi voir en un coup d’oeil le ton de l’itération en traçant le nuage des post-its.

Le timeline est plus pratiquée lors de rétrospectives de livraison que de sprint. Pensez dans ce cas à tracer une ligne qui va au delà de la mise en production, car le travail de l’équipe ne s’arrête pas avec la MEP.

3. Générer des réflexions

Définir les priorités

Il n’est pas simple de trouver des solutions à l’ensemble des problèmes identifiés en une heure ou deux. Même quand cela est possible, trop de solutions sont nuisibles car frustrantes à la longue : elles ne seront simplement pas réalisées d’ici la prochaine itération, ni la suivante, et ainsi de suite.

Il vaut donc mieux avoir moins de problèmes à traiter et de les traiter réellement. Un système de votes à jetons permet de tenir compte de l’importance accordé à chaque problème par chacun.

Donnons par exemple 5 jetons à chacun, positionnables sur un ou plusieurs problèmes. L’avantage de ce système par rapport à un vote classique est la pondération. Je peux donner tous mes jetons à un problème qui me parait infiniment plus important.

On peut aussi simplement faire un vote à main levée ou parler de vive voix du problème qui nous parait principal. Il faut quand même veiller à ce que des voix de ne soient pas oubliées, en particulier si la note de confiance était moyenne.

Brainstorming

Les brainstorming peuvent prendre des formes très diverses. L’une d’entre elle consiste à procéder à tour de rôle : chacun propose un sujet à tour de rôle. Toutes les propositions de sujets sont notées sur le tableau. L’objectif est de brasser des idées. Un vote par jetons est ensuite effectué pour traiter un sujet, au moins pour commencer. C’est seulement dans un troisième temps, qu’à tour de rôle encore, chacun propose des solutions. Nous sommes assurons de cette façon que tout le monde a pu s’exprimer.

Les 5 pourquoi

Cet exercice part du principe où la première solution est rarement la meilleure. Il permet de chercher de creuser un peu plus et d’obtenir des solutions de fond.

On tourne le problème en pourquoi, cinq fois de suite.

1. “Pourquoi y a-t-il autant de bugs?” Parce que nous ne les voyons qu’à la MEP.

2. “Pourquoi ne le découvrons nous pas avant ?” Parce que la recette n’est pas assez poussée.

3. “Pourquoi la recette n’est pas assez poussée?” Parce que nous ne lisons pas la procédure de recette.

4. “Pourquoi ne la procédure de recette n’est-elle pas suivie?” Parce que nous ne sommes pas sure qu’elle soit à jour et qu’elle est trop longue. Nous sautons parfois certains passages.

5. “Pourquoi n’automatisons pas la recette”?

Le défaut de cette approche est qu’elle met de coté certaines solutions. J’aime noter quand même les solutions alternatives, sous forme d’arbre, au moins pour plus tard et voir avec l’équipe si elle souhaite aussi décliner les autres branches en d’autres pourquoi.

Les diagrammes d’effets de Weinberg constituent aussi un exercice intéressant pour élargir la vision du problème.

La pesée

Cet exercice a été décrit sur le Touilleur-express et j’ai trouvé que le non “la pesée” reflétait bien l’esprit :-). Il est intéressant car il s’appuie sur des éléments produits pendant le sprint (les post-its de tâches du scrumboard) et génère des discussions.

Une ligne est tracée pour indiquer le temps passé sur une tâche. Les développeurs doivent placer les taches dessus en fonction du temps qui a été nécessaire pour les réaliser.

L’équipe communique entre elle pour expliquer ce qu’ils ont fait et se mettre d’accord.

Ensuite, les estimations sont comparés à ce temps réel. L’équipe peut alors chercher des explications aux écarts et comment y remédier.

4. Planifier des actions d’amélioration

Il vaut mieux qu’il y ait peu d’actions décidées et qu’elles soient réalisées à l’échéance. Par ailleurs, une action avec un responsable a plus de chance d’être concrétisée.

Le Plan Do Check Act (PDCA) permet d’avoir un suivi des actions et de vérifier qu’elles résolvent effectivement le problème.

5. Clore la rétrospective

C’est le moment de se dire au revoir. J’ai découvert un exercice assez sympa à la conférence Agile France, surtout s’il y a des participants externes à l’équipe de développement : le lancer de fleurs. Je remercie une personne en précisant ce qu’il m’apporte : “Je te remercie de …. Cela me permet de … “. Cela nous force à trouver des bons côtés et est assez marrant à faire.

Le Return On Time Invested (ROTI) est plus courant : nous évaluons à main levée la valeur apportée par l’heure ou les deux heures passées ensemble, par rapport à notre activité habituelle. Pour faire court : une note de 3 signifie que c’est équivalent; une note de 4 indique que le temps passé en rétrospective nous a apporté plus que si nous l’avions passé à travailler “normalement”.

Conclusion

Les rétrospectives m’ont énormément apportée personnellement, ainsi qu’à l’équipe et tout autant au produit. Elle a fait ressortir des problèmes invisibles, a débloqué des situations enlisées, a laissé de la place au dialogue et aux actions quand nous avons raté des itérations. Elle a permis de souffler.

S’il n’y avait qu’une chose à prendre dans Scrum, ce serait la rétrospective. D’ailleurs, je mettais très souvent des 4/5 en ROTI, voire des 5. Puis le temps passant, le 3/5 devenait de plus en plus de mise. Les rétrospectives m’apportaient de moins en moins. Nous y reviendrons dans un deuxième billet, sur les rétrospectives manquées.

Crédit Photos

Photo de la femme qui s’étire : regime-maigrir-minceur.com
Dessin des doigts pointés : http://sainte-anne.cathocambrai.com
Urne : http://blog.lib.umn.edu
Brainstorming : http://solhisharif.files.wordpress.com
Garcon qui souffle : http://ohmypod.generationmp3.com

C
Florence Chabanois (0 Posts)

Méthodes agiles et développement en Java.


Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>