Martin Séguin|

La gestion de projet classique et l’agilité partagent beaucoup de choses en commun. L’une d’entre elles est le Post Mortem vs la rétrospective. Lors des formations Agile / SAFe que je donne c’est un des sujets qui revient souvent. On me demande si c’est la même chose et ma réponse est “Noui”. Il y a des différences majeures dans la manière de les faire ainsi que dans leurs raisons d’exister.

Le Post-Mortem est, comme le nom l’indique, une forme de rétrospective à la fin du projet. Donc, quand tout est terminé. L’idée est excellente. Malheureusement, elle se produit trop tard, car l’équipe est désormais dissoute. Ce qui en ressort sera “peut-être” utilisé ailleurs par certaines personnes concernées. Pour le reste, ça se résume par “Avoir su que …”

Pour ce qui est des rétrospectives, le principe #12 de l’agilité dit ceci : « À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. » Ça fait en sorte qu’on le fait plus souvent. En Scrum, c’est fait à chaque Sprint. Du côté de SAFe, on le fait aussi à la fin des itérations pour le niveau équipe, mais on le fait également à la fin d’un Intervalle de Planification (PI) dans le but de voir comment le train peut lui aussi s’améliorer et bénéficier de l’expérience acquise.

Il existe plusieurs méthodes pour faire ces rétrospectives. La méthode classique à 3 colonnes :

1. Qu’est-ce qu’on veut améliorer; 
2. Qu’est-ce qu’on veut arrêter; 
3. Qu’est-ce qu’on veut conserver.

Les gens écrivent leurs points sur des post-it, papier ou virtuel, pendant la première partie de la rencontre. Par la suite on les passe en revue dans le but de les expliquer. Et en dernier on élabore en équipe un plan d’action pour les éléments dont on pense avoir le temps d’implanter pendant l’itération qui suit. Inutile de faire un plan d’action pour tout, ça ne se réalisera pas.

Il existe des dizaines de méthodes différentes pour faire ces rétrospectives. Il existe des livres et des sites Web dédiés à ce sujet. Donc, il y a moyen de faire un peu de variété. Les équipiers aiment bien le changement, mais pas trop. Une fois de temps en temps c’est apprécié, mais pas à chaque itération. Ils aiment savoir d’avance comment les choses vont se passer. Les sujets de rétrospectives doivent monopoliser la conversation et non la méthode de rétrospective.

Étant Lego Serious Play Facilitateur certifié, j’utilise régulièrement la méthode Lego pour faire des rétrospectives dans les équipes Scrum ou encore au niveau du train lors de la rencontre de résolution de problème. Le « Problem-Solving Workshop » est à la fin d’un PI dans la rencontre appelée « Inspect & Adapt ». C’est le moment où on fait une forme de rétrospective sur tout ce qui s’est passé au niveau train lors du dernier Intervalle de Planification (PI). Le fait d’emmener un groupe de plusieurs dizaines de personnes à utiliser des Lego pour faire la rétrospective offre un défi d’organisation, mais c’est très faisable avec un peu d’expérience. Ça fait plusieurs fois que je le fais, et ce même dans des endroits où les gens travaillent en cascade et non en agilité. Les résultats d’une session du genre sont très inspirants pour les équipiers, car ils se rendent compte qu’ils font partie d’une équipe beaucoup plus grosse que leur équipe Scrum habituelle. 

Un défi demeure, peu importe la méthode : faire en sorte que les plans d’action soient implantés. Mais ça, c’est un autre sujet.