Post mortem meeting

post mortem meeting
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.

[ Article lu 1 fois aujourd'hui ]
A propos Judicaël Paquet 633 Articles
  Paquet Judicaël (coach agile et devops sénior) Mes activités en France et en Suisse : - architecte de transformation agile - formations agiles personnalisées - sensibilisations et coaching de manager - audits de maturité agile et de situations - coaching agile (équipes, orga, product owner, scrum master, coach agile) Spécialités : scrum, kanban, management 3.0, agilité à l’échelle, lean startup, méthode agile. [Suisse/France]

Soyez le premier à commenter

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée.


*


Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.