Comment faire un post-mortem réussi ?
Voici ma recette perso
C’est quoi un post-mortem ?
C’est une réunion organisée typiquement suite à un incident en prod pour en échanger. Les buts sont de :
- Comprendre ce qu’il s’est passé
- S’améliorer pour que cela ne se reproduise plus, ou que les conséquences soient moins graves
Selon le contexte, un post-mortem peut également être organisé pour d’autres occasions. Dans tous les cas, c’est toujours parce qu’il s’est passé quelque chose qui n’aurait pas dû arriver dans un monde idéal. Généralement, ce quelque chose est grave.
Selon le problème et la marge de manoeuvre pour améliorer la situation, le but peut être moins radical et se contenter de réduire la probabilité d’apparition du problème, ou bien de réduire les conséquences lorsque le problème arrive.
C’est un peu comme une rétro, quoi ?
Il y a sans aucun doute des similitudes entre les post-mortem et les Rétrospectives de Scrum. Il y a aussi des grosses différences :
La périodicité :
- La Rétrospective, en Scrum du moins, est un événement qui a lieu à intervalles réguliers : à chaque fin d’itération. C’est un moment formel pour encourager l’amélioration continue.
- À l’inverse le post-mortem a lieu parce qu’il y a eu un événement grave qui mérite d’urgemment se pencher dessus.
La dynamique :
- Lors d’une Rétrospective on va chercher à s’améliorer sans spécifiquement s’attarder sur les problèmes. On va aussi bien creuser ce qui s’est bien passé que ce qui s’est moins bien passé.
- Lors d’un post-mortem, par définition, on va se pencher sur un problème.
Le focus :
- Les thèmes abordés ne sont pas toujours connus à l’avance lors d’une Rétrospective. L’équipe se retrouve et échange au global du déroulé de l’itération, sans forcément avoir un focus spécifique.
- Lorsqu’on organise un post-mortem c’est pour parler d’un problème bien précis. Nous verrons d’ailleurs plus loin que c’est sa force : cela permet d’opter pour des formats de réunion très courts et très efficaces.
Le temps nécessaire :
- Une bonne Rétrospective nécessite un minimum de temps. Selon la durée de l’itération, il faut compter de une à trois heures, typiquement 1h30 pour une itération de deux semaines.
- Un post-mortem bien préparé et bien encadré se déroule en 15 à 30 minutes.
Le déroulé :
- Une Rétrospective peut prendre bien des formes différentes. Parfois même elle peut s’apparenter plus à du team-building qu’à une recherche d’axes d’amélioration. C’est avant tout un temps donné à l’équipe pour s’améliorer sans être prescriptif sur la forme.
- Un post-mortem est analytique. On récapitule les faits, on trouve les causes racines, on définit des actions d’amélioration.
Les personnes présentes :
- Une Rétrospective ne concerne que l’équipe. Par contre, toute l’équipe est conviée : aucun membre de l’équipe n’en est exclu.
- Un post-mortem requiert la présence de tout acteur ayant une information pertinente à donner sur les faits, ou en capacité d’aider le groupe à mieux comprendre la situation ou pour prendre en charge des actions. On invite quiconque est utile au bon déroulé du post-mortem.
Le compte-rendu :
- On applique souvent la règle de “Ce qui se passe à Vegas, reste à Vegas” en parlant de la Rétrospective pour permettre de faire sortir les vrais problèmes. La rédaction de compte-rendus est plutôt une mauvaise pratique pour les Rétrospectives, ou alors à se concentrer uniquement sur les actions prises (qui devront être tracées quoi qu’il arrive) sans s’attarder sur le déroulé qui y a mené.
- Le compte-rendu d’un post-mortem est essentiel. Il permet de bien préparer la réunion en amont, élément-clé d’un bon post-mortem, à la fois productif et rapide. De plus, les conclusions du post-mortem intéresseront certainement très largement le reste de l’organisation : autres équipes, managers, clients… Ces derniers seront d’ailleurs aussi intéressés par comprendre ce qu’il s’est passé, que de savoir quelles actions vont être mises en place.
Est-ce que les post-mortems sont compatibles avec Scrum ? On fait déjà des Rétro. Y aurait-il un intérêt ?
Oui, les post-mortems sont compatibles avec Scrum et peuvent apporter de la valeur :
- Comme vu dans la section précédente, les Rétrospectives et les post-mortems sont différents à bien des égards.
- Les post-mortems sont particulièrement intéressants pour adresser des sujets qui vont au moins partiellement dépasser l’équipe : équipe Ops, interactions autour d’un module commun, impact fort sur le client, conséquences d’une décision produit imposée… Le post-mortem donne un cadre flexible et efficace pour inviter toutes les bonnes personnes et avoir les bonnes discussions.
- Les post-mortems peuvent être organisés de manière ad-hoc et sans attendre. Ils peuvent être vu comme de l’amélioration continue, alors que la Rétro offre un moment propice à l’équipe pour se ressourcer et prendre du recul par rapport à elle-même et ses manières de travailler.
Quelques points d’attention cependant :
- Si l’équipe utilise la Rétrospective uniquement comme moment pour analyser les problèmes et trouver des solutions, les post-mortems peuvent être redondants.
- Des post-mortems mal exécutés risquent de se concentrer sur les symptômes plutôt que sur les causes racines, sur les problèmes de fond. Cela pourrait alors déteindre sur le déroulé des Rétrospectives qui suivraient le même schéma superficiel.
À noter, si votre équipe ou organisation peine à pratiquer avec rigueur la Rétrospective, les post-mortems peuvent être un premier moyen de se sortir de l’ornière.
Ca se passe comment un post-mortem ?
Il y a 3 phases, que l’on retrouvera dans le compte-rendu du post-mortem :
- Les faits : objectifs et sans jugement, listés chronologiquement, horodatés dans la mesure du possible.
- L’analyse de cause racine (root-cause analysis) : quelles sont les causes derrière les différents problèmes identifiés ? Quelles sont les causes derrière ces causes ? Jusqu’à trouver la cause racine.
- Les actions d’amélioration : avec un responsable pour chaque action, et si possible une date à laquelle vérifier la mise en place de l’action.
En pratique, la phase 1 est quasi-intégralement effectuée en amont de la réunion : c’est la préparation du post-mortem. Une simple relecture est faite en séance pour bien aligner tout le monde et éventuellement apporter des corrections mineures.
La phase 2 et la phase 3 constituent le cœur du sujet. C’est là qu’on construit le plus de valeur. Elles sont à faire en séance avec tous les participants.
L’animation : accuser les process et jamais les personnes
La manière d’animer le post-mortem est cruciale.
Ainsi la phase 2, l’analyse de cause racine, peut très bien s’animer avec un 5 pourquoi. Mais attention à bien expliquer et montrer que ce ne sont pas les personnes que l’on cherche à accabler, mais bien à mettre en défaut les process.
C’est d’ailleurs un des principes de l’amélioration continue en Lean : “Doux avec les personnes, dur avec les situations”
Il sera donc essentiel de ne jamais s’arrêter à une cause du type “telle personne n’a pas fait cela” pour bien demander : “pourquoi cette personne ne l’a pas fait ?” et à ne pas hésiter à faire quelques suggestions qui recentrent bien l’accusation sur le système et non pas sur les personnes : “manque de temps ? Manque d’expertise ?”
Toutes les réponses sont bonnes à prendre, mais à chaque fois il faut bien recentrer sur le système : “Il a été feignant, il aurait dû le faire.” → “Qu’est-ce qui fait que cette tâche est rébarbative, ou qu’on l’oublie ?” et ainsi de suite…
Il faut parfois aussi recentrer les échanges sur l’équipe elle-même : “On a mal testé parce qu’on ne nous a pas affecté de testeur.” → “Pour quelles raisons ne testez-vous pas assez en l’absence de testeur ? Quels sont les moyens qui vous manquent ? Manque de temps ou d’expertise ?”
Déroulé typique
- Dans la mesure du possible, essayer de prendre des notes alors que l’incident est en cours : le support au post-mortem peut déjà être initié.
- Une fois l’incident terminé, définir qui seraient les bons participants au post-mortem, trouver une date la plus proche possible qui conviendrait à tous et envoyer l’invitation.
- Préparer la chronologie des événements. Créer le support au post-mortem si ce n’a pas déjà été fait. Solliciter diverses personnes clés pendant l’événement pour construire cette chronologie.
- Afficher le support au post-mortem pendant la réunion de post-mortem.
- Ouverture du post-mortem par la lecture ensemble de la chronologie. Corrections en fonction des retours des participants.
- Discussions guidées pour définir les causes racines des différents problèmes et dysfonctionnements identifiées dans la chronologie.
- Discussions ouvertes autour des causes racines pour définir les actions d’amélioration.
- S’assurer que chacun est d’accord avec les actions proposées et sur les personnes responsables de ces actions.
- Communiquer largement le support au post-mortem
- Effectuer un suivi des actions
Que pensez-vous de cet article ?
Si vous avez aimé cet article, merci de le partager !
Et pensez à souscrire à ma future newsletter.
À bientôt 😊