Retrospective

Un article de Agora2ia.

(Redirigé depuis Rétrospective)



Sommaire

Structure

Agile Retrospective

Le plan suivant repose sur le livre Agile Retrospectives: Making Good Teams Great de Esther Derby et Diana Larsen. C'est également celui que vous retrouverez dans le jeu Alchimiste Agile.


Matériel :


"A la pêche aux bonnes actions"

Un autre plan de Retrospective de mon cru, basé sur mon experience (j'ai joué ce plan sur une retrospective qui a durée 2h) :

  • Starfish pour identifier les problèmes et les opportunités de l'équipe avec 5 questions au lieu des 3 habtuelles
  • SpeedBoat pour recueillir des données
  • Fishbone pour en extraire les causes profondes
  • FiletDePecheAuxActions pour en identifier des actions

Autres pratiques

Cependant, vous pourrez trouver d'autres plans de rétrospectives sur le site RetrospectiveWiki.org. Cela pourra vous permettre de sortir de la routine de rétrospectives trop fréquentes... Routine qui est à mon avis le pire ennemi de la vocation première de la Rétrospective : identifier les lacunes sous jacentes pour en apprendre.


Il y a aussi ce site qui génère au hasard une séquence d'activités (1 pour chacune des 5 phases) parmi sa base d'activité :

Présentation

Késako

Voir /Kesako


Slogan

Transmuter son expérience en compétence.

Apprendre de ses erreurs... Et de ses victoires.


Vocation

Une bonne façon de progresser est d'apprendre de ce que l'on a fait pour :

  • Améliorer le mauvais (pas seulement...)
  • Garder le bon (... aussi !)

Pour cela, on peut poser les 3 questions suivantes :

  • Qu'avons nous fait de bien (à refaire) ?
  • Qu'avons nous pas fait (à tord) ?
  • Que pourrions nous améliorer ?

Ca reservira même si on ne fait le même projet : on retrouvera bien une situation équivalente, des technologies équivalentes, des profiles équivalents, des problèmes équivalents...

Dépasser les évidences : on a tous une idée sur qui est le responsable de tel problème (bien souvent c'est pas nous ;) et on sait comment on aurait fait à sa place... Mais en creusant un peu, on s'aperçoit souvent que le problème n'est pas si évident, notre solution pas si luminueuse, la cause profonde finalement bien profonde.

Se concentrer sur que ce qui doit être fait pour améliorer le processus est plus pragmatique que de s'attarder sur ce qui n'a pas marché.


Caractéristiques

  • C'est donc une réunion, une cérémonie participative, un moment de réflexion collaboratif.
  • C'est un outil d'analyse et de prise de décision
  • La faire fréquemment, ne pas attendre la fin, la faim.
  • La rétrospective introduit des changements de manière graduelle, et ne vise pas à tout changer de manière radicale.
  • Focalisée sur le processus (notre façon de travailler) et non pas le livrable (ce que l'on produit).
  • Dés que l'on est une équipe, c'est justifié.
  • Pas besoin d'une longue expérience dans les processus pour les améliorer, puisque la solution viendra de l'équipe, pour l'équipe. Tout au plus quelques règles sur l'animation d'une rétrospective. En effet, la rétrospective est un processus empirique, où l'on inspecte et adapte au fur et à mesure que l'on avance.

Mais attention, on peut parfois faire sortir l'anguille de sous la roche avec ce puissant outil. Une équipe avec des crispations latentes depuis longtemps qui a soudain l'occasion de s'exprimer (pour s'améliorer) peut faire ressortir baucoup d'energie lors de premières retrospectives. Ne pas transformer l'étincelle de l'amélioration continue en explosion de crispations enfin avouées.

La portée de la retrospective depend de ses participants : la première tâche de l'animateur d'une retrospective est donc d'inviter les bonnes personnes :

  • l'équipe
  • le product owner
  • le chef de projet
  • le DBA
  • des gens du déploiement / exploitation
  • de la qualité
  • ...


C'est le but du livre Project Retrospectives: A Handbook for Team Reviews de Norman L. Kerth. On retrouve cela sur le site Retrospectives.com.


Devant le constat qui s'imposait que la Rétrospective est une arme redoutable, et pas seulement pour les équipes agiles ou les projets informatiques, que j'ai proposé à François Bachmann de créer un jeu : l'Alchimiste Agile était né. Le formtateur que je suis allait avoir un outil pour expliquer cette pratique par le jeu à un public hétérogène.

Pourquoi

Pourquoi faire des rétrospectives ?

  • Pour s'améliorer
  • Pour continuer à motiver l'équipe (en supprimant ou réduisant les causes de démotivation)

Les axes d'amélioration d'une équipe sont multiples :

  • Sa productivité
  • Ses compétences
  • Sa cohésion et la collaboration de ses membres
  • Sa communication interne ou externe,
  • La qualité de ses livrables
  • L’intérêt et la motivation des membres
  • Les règles de travail (working agreements)
  • ...

Mais pourquoi ne pas se contenter d'appliquer des méthodes déjà formalisées ?

  1. Tout d'abord, il n'est pas évident de connaitre certaines méthodes dans leur ensemble.
  2. Ensutie, même si on les connait (toutes ? chacune intégralement ? vraiment ?), il n'est pas évident de les appliquer dans son propre conseil.

C'est pour cette raison qu'un processus empirique formalisé tel que la Rétrospective permet de progresser de manière contextuelle, donc plus adaptée et donc plus efficace... Et avec un meilleur consensus et engouement.


Conseils

Revue vs. discussion

Afin de ne pas entasser les "bonnes intentions" il est important de commencer la rétrospective par une revue des actions identifiées lors de la précédente. Au même titre que l'on commence un planning game par la revue des stories restantes du précédent.

Or, il arrive, surtout lorsque l'on débute (mais pas seulement), que des actions restée dormantes, délaissées, pendant l'itération se déclenchent à l'occasion de cette revue. Or, au même titre que le standup meeting n'est pas l'occasion de faire une réunion de conception, la rétrospective n'est pas le moment de résoudre les actions, sinon vous allez immobiliser tous les participants pendant la journée ! Je pense qu'on peut se laisser 4 ou 5 minutes de discussion si cela permet effectivement de converger ou de prendre une décision à l'occasion de la réunion de tous les participants, mais si cela commence à durer, l'animateur devrait avoir le courage de dire "Stop!". L'action n'est pas DONE, et on la reconduit.

Cette phase est donc un compromis entre ne pas s'éterniser à résoudre les actions maintenant mais se laisser quelques minutes pour voir si on ne peut pas gagner du temps en concluant une action maintenant. Et puis il ne faut jamais sous estimer l'importance de ce qui peut se passer lors d'une réunion participative.


Pourrissement des actions

Au même titre que les Stories peuvent s'enliser dans le backlog, les actions de la rétrospective peuvent s'immobiliser dans l'Impediment Backlog. On peut donc reprendre cette technique du Kanban qui consiste à marquer la vieillesse des actions.

Si on a un outil numérique, on peut préfixer les actions par "0s" lorsqu'elles rentrent dans une itération, puis "1s" si elle est encore là au sprint suivant, puis "2s" si elle est encore là à celui d'après... Et si on travaille avec des fiches Bristol, on peut rajouter une pastille à chaque nouvelle itération que prend la tâche.

L'idée est ainsi d'avoir un marqueur visuel de l'âge de la tâche. On peut alors travailler sur les raisons qui font que ces tâches trop vieilles apparaissent.


Au delà

  • La présentation de Emilie Franchomme & Caroline Damour-Nobi à Agile France 2012 : Des mots, des maux? Démo!, les facettes de la revue de sprint.


Retour d'experience

Nous avions fait une rétrospective à l'époque (ouaouh, j'suis vieux ;o) où je travaillais avec Dominic, en fin d'un projet de 3 ans.

La "réunion" avait durée la journée.

Les 3 grandes questions à se poser :

  • Qu'avons nous appris ?
  • Que ferions nous différemment la prochaine fois ?
  • Qu'est ce que nous n'avons toujours pas réussi à comprendre / améliorer ?

Quelques bonnes idées à mon sens :

  • Rendre le plan public, voire le construire avec les participants
  • Afin qu'ils puissent "préparer" la "réunion", des réponses.
  • Diviser le temps imparti à la réunion en 2, et faire 2 réunions, afin de laisser mûrir certaines réponses / réflexions
  • Dominic nous avait demander à chacun d'apporter la "chose" (objet, bout de code, doc...) qui selon nous symbolisait le mieux le projet

Tu pourras trouver des infos sur http://www.retrospectives.com

Enfin, je suis content de voir que d'autres " retrospectent ", cette pratique étant à mon sens aussi bénéfique que rare !

PS : le terme de réunion me dérange pour une rétrospective....


AAR : The After-Action Review


Ressources

Sites

Livres