Post mortem meeting

J’ai décidé de parler d’une pratique qui se faisait beaucoup dans certaines méthodes agiles : le post mortem meeting ! Et je suis toujours étonné de ne voir quasiment aucune équipe scrum mettre en place cette pratique.

Post mortem meeting – définition

Cette cérémonie peut sembler s’apparenter à la rétrospective mais son concept est au final très différent. La post mortem meeting est un évènement qui se déclenche lors qu’un gros problème est arrivé et qu’il a été réglé (ou du moins que le risque associé n’est plus présent).

Voici les caractéristiques de celle-ci :

• elle se réalise de façon ponctuelle
• on se focalise sur le problème pour trouver une solution
• elle n’a pas de durée fixe

Je recommande aux équipes scrum d’utiliser cette pratique en complément de la rétrospective.

En Crystal Clear, certaines « reflexion » ont aussi ce principe de post mortem meeting ; Pareil pour les rétrospectives en extreme programming.

Ne pas attendre la rétrospective !

Attendre la rétrospective de fin de sprint va amener son lot de problème. Lorsque l’équipe a rencontré un gros problème, elle a la nécessité de faire un post mortem meeting pour :

• ne pas oublier certains éléments
• s’assurer que cela ne va pas créer de la dette émotionnelle
• laisser la rétrospective s’opérer sans focus
• ne pas prendre le risque de revivre la situation

En effet, si l’équipe attend la rétrospective, elle pourrait se focaliser sur le problème rencontré… Cependant, si le régler est essentiel, il n’était peut être pas l’axe d’amélioration le plus important à avoir.

De plus, si le post mortem se fait plus ou moins à chaud, la rétrospective se fera en revanche à froid… Les résultats de ce premier pourraient également remonter lors de la rétrospective.

La Post mortem meeting suit d’autres approches

Dans les pays anglophones agiles, une notion similaire revient sur le devant de la scène ; notion qui d’ailleurs fait une fois de plus référence à la philosophie de l’Extreme Programming.

Le « A zero bug Policy »

Pour faire simple, ce concept explique qu’un bug ça se corrige ou ça se supprime ; par contre, on refuse dans tous les cas de vivre avec. Si cette approche va dans le même sens que le post mortem, c’est dans l’idée de dire : « on ne reporte pas à demain ce qui a trop d’importance ».

Utilisez vous cette pratique au sein de vos équipes ? N’hésitez pas à nous partager vos feedback sur ce sujet.