Qu’on l’appelle Maxi Rétro, Rétrospective Projet, ou encore Process Rétrospective, le Post Mortem fonctionne un peu comme une rétrospective de sprint, mais à plus grande échelle: en vue de vous améliorer sur les futures releases, il vous permettra d’identifier et de rectifier les principaux problèmes, ainsi que de mettre en avant les points sur lesquels capitaliser.
Attention ! Mal organisé, il peut être perçu négativement. Certains croiront qu’on va encore leur faire des reproches, ou qu’il s’agira d’un simple pugilat, moment idéal pour régler ses comptes. Des collègues déçus ne voudront pas y participer sous prétexte que les problèmes soulevés ne seront jamais résolus. Et ça se comprend, personne n’aime perdre son temps !
Voici donc 6 étapes qui devraient le rendre plus pertinent aux yeux de tous :
- Prendre des notes tout au long de votre release
- Fournir en amont de l’atelier la documentation, le déroulé et les règles à respecter
- Recruter les participants pertinents et les facilitateurs impartiaux
- Choisir un format collaboratif et bien time-boxé
- Identifier les thèmes et propositions d’actions avec “les gens qui font”
- Réunir les décideurs, les informer et trouver un compromis
1. Prendre des notes tout au long du processus de conception et de développement
Cela va vous aider à garder en mémoire tous les évènements marquants, c’est à dire tout fait concret ayant eu un impact positif ou négatif sur le déroulé de la release : l’arrivée d’une personne clé dans l’équipe, l’instabilité de certains environnements, le choix d’une solution technique, des changements de périmètre récurrents …
Les plus assidus pourront par exemple créer une timeline où inscrire au fil du temps les post-its d’évènements comme décrit ci-dessous. Bien sûr, cela peut paraître fastidieux mais noter ces points au fur et à mesure vous permettra de mener un post-mortem de fin de release pertinent et de bonne qualité.
Autre astuce : Vous pouvez aussi récupérer les comptes rendu des rétrospectives de sprint de votre équipe.
2. Fournir en amont la documentation, le déroulé et les règles à respecter
Avant même de planifier l’atelier, il va falloir inciter les personnes à venir s’exprimer. Vos collègues seront d’autant plus motivés si vous leur annoncez en amont les objectifs attendus et un déroulé précis :
- Communiquer une documentation en guise de support à l’atelier. Je ne vous parle pas de rassembler ici tous vos liens Confluence que personne ne lira. Mais plutôt de créer un document très synthétique et facile à lire :
- Rappeler les objectifs de départ, les résultats post MEP
- Photographier votre timeline de release si vous avez une
- Décrire de manière claire l’agenda de l’atelier :
- Durée
- Déroulé de la séance
- Nombre d’ateliers prévus (si il y en plusieurs)
- Output attendus
- Annoncer les règles à respecter :
- Avoir lu la documentation
- Respecter les règles de tenue en séances : exemple “pas de téléphones portables”
- Respecter les règles de couleurs des post-it & restitution écrite
- Etre concis et bref sur des questions relatives à la release
- Enoncer les feedbacks de manière factuelle : s’en tenir aux faits sans les interpréter
- Respecter une durée limite de prise de parole qui sera garantie par la présence d’un timekeeper
3. Recruter les participants pertinents et facilitateurs impartiaux
Durant cet atelier, je recommande vivement d’exclure les profils de type “décideurs/top managers” et de ne rassembler que les personnes impliquées dans la conception opérationnelle du produit i.e développeurs, product managers, testeurs, UX...
Pourquoi ? On évite ainsi de créer des biais sur les feedbacks. Certaines personnes peuvent être mal à l’aise en leur présence et ne plus être objectives pour des raisons bien souvent politiques. Par exemple, l’opinion de votre N+7 peut être perçu comme une hippo c’est à dire une Highest Paid Person’s Opinion qui peut complètement cannibaliser votre Post Mortem. Voici quelques conseils à lui soumettre en off si il veut quand même y assister : Beware of the HIPPO!
N’oubliez pas de vous armer :
- d’un timekeeper garant du temps
- d’un animateur garant du respect du déroulé (Coach Agile, Scrum Master) et des règles énoncées plus haut. Vous même pouvez combler le rôle mais pour plus d’impartialité, il vaut mieux faire appel à une personne externe à l’équipe si possible.
4. Choisir un format collaboratif et bien time-boxé
Pour le déroulé, je conseille le format simple SAD/MAD/GLAD plutôt que des formats avec questions ouvertes qui demandent plus de temps de restitution. Ici, vous gagnez du temps et le feedback de chaque intervenant est mieux structuré grâce aux 3 catégories :
- GLAD : points positifs sur lesquels capitaliser
- SAD : points négatifs à corriger
- MAD : points très irritants à corriger immédiatement
Comptez environ :
- 5 à 10 minutes de temps de parole par personne
- Ne pas dépasser une durée de 1h30 : plus long, votre atelier sera perçu comme insoutenable. Si le nombre d’intervenants est trop élevé, n’hésitez pas à créer plusieurs séances en nombre restreint et faire une restitution globale.
5. Identifier les thèmes et propositions d’actions avec “les gens qui font”
Une fois les feedbacks récoltés, regroupez les par grand thèmes et retenez ceux jugés importants. Réunissez à nouveau l’équipe et essayer de brainstormer collectivement sur des solutions concernant les points SAD/MAD. Vous devez sortir de cet atelier avec des propositions d’actions correctives et les acteurs pouvant les mettre en oeuvre. Tout cela doit émaner de l’équipe, et ce, qu’il s’agisse d’un correctif interne - que l’équipe elle même peut porter - ou d’un correctif externe - dont la mise en place ne peut être effectuée que par des décideurs de plus haut niveau. Cet exercice demande un réel effort collectif.
Pourquoi avoir cette réflexion?
Cela vous servira de base de discussion pour les points négatifs qui nécessitent l’intervention de décideurs pour pouvoir être solutionnés. De plus, ce sont ceux qui font qui sont parfois plus à même de proposer des solutions adéquate et répondant concrètement à leurs problématiques.
6. Réunir les décideurs, les informer et trouver un compromis
A la suite du Post Mortem, les personnes pertinentes (vous - en tant que Product Owner, le Scrum Master, le Coach Agile), vont devoir rassembler les décideurs et leur soumettre les problématiques critiques que l’équipe ne peut gérer elle-même.
Si vous êtes dans une entreprise mature en terme d’agilité, pour qui ces remontées sont déjà considérées comme faisant partie intégrante du processus d’amélioration continue, tout devrait se passer sans difficulté : vous serez entendu et vous essaierez de vous accorder sur 2 ou 3 rectificatifs actionnables à court et moyen terme avec des porteurs d’actions. Les sujets demandant plus de réflexion seront écartés pour le moment mais à approfondir dans la durée.
Si votre entreprise n’a pas atteint cette maturité, alors vous pourrez dans un premier temps vous contenter de les informer. Ainsi, vous essayerez au moins de créer une discussion et espérer une réaction.
Un Post Mortem bien organisé dévoile bien souvent plus de failles organisationnelles que de problèmes basiques de mésentente entre personnes. Comme tout atelier d’amélioration continue, les corrections doivent faire l'objet d'actions et de suivi de la part de leurs porteurs, qu'il s’agisse d’une décision stratégique, organisationnelle ou juste opérationnelle. Les bonnes pratiques quant à elles, doivent être identifiées et testées dans l’ensemble de l’organisation.
