Données d'exemple. Fieldnote est une entreprise fictive qui sert à remplir les 61 boards, pour que les exemples racontent une seule histoire.
Fieldnote, le post-mortem sans blâme après la release de mars qui a cassé l'upload photo pendant deux jours : Tom, les deux ingénieurs de la release, Julien, et Karim en facilitateur neutre.
Ce que l'équipe en a tiré
La salle attendait 'qui a mergé' ; la chronologie a montré que le merge était propre et que le trou était le banc d'appareils. Trois actions, toutes sur le banc et le calendrier.
Comment l'animer
Préparation
Tous ceux qui ont touché l'incident, plus un facilitateur qui n'y était pas impliqué. Le facilitateur est le seul à pouvoir interrompre.
Rassemble la chronologie brute avant la session : alertes, messages, déploiements, avec horodatage. Affiche-la sur le board telle quelle, sans interprétation.
Quatre colonnes : Chronologie, Causes, Ce qui a bien marché, Actions. Écris la règle sans blâme en haut du board en gros.
Déroulé
5 min
Lire la règle Dis-le : on part du principe que chacun a agi avec la meilleure information qu'il avait. On répare le système, pas les gens. Quiconque nomme un coupable est arrêté.
25 min
Parcourir la chronologie Lis la chronologie minute par minute. Chaque participant ajoute ce qu'il savait et voyait à chaque moment. Corrige les horodatages, ajoute les événements manquants.
25 min
Causes À chaque point de bascule, demande pourquoi jusqu'à cinq fois. Arrête-toi à la première cause qui est un process, un outil ou une information manquante. Jamais à une personne.
10 min
Ce qui a bien marché Liste ce qui a limité les dégâts : une alerte rapide, un bon rollback, quelqu'un qui a appelé la bonne personne. Ce sont des choses à protéger.
25 min
Actions Quatre actions maximum, chacune évitant une cause ou raccourcissant la détection ou la récupération. Responsable et date. Publie le rapport à toute l'organisation sous 48 heures.
Pièges
Ne laisse pas la personne la plus proche de l'incident écrire la chronologie seule. Elle comble les trous avec sa mémoire, et la mémoire est indulgente avec elle-même.
N'arrête pas les pourquoi à 'X a fait une erreur'. Demande pourquoi le système a laissé cette erreur atteindre la production.
Ne garde pas le rapport privé. Un post-mortem que personne hors de l'équipe ne lit n'apprend rien à personne hors de l'équipe.
Ensuite
Le rapport est publié et les actions suivies comme n'importe quel élément de backlog, avec un point à 30 jours. Les causes qui reviennent d'un post-mortem à l'autre relèvent de l'Inspect & Adapt ou des OKR de la direction.