Resumo rápido
Uma retrospectiva sem culpa assume que as pessoas tomaram decisões razoáveis com a informação que tinham. A reunião procura as condições que tornaram o erro provável: alertas ausentes, um runbook confuso, uma janela de deploy, uma revisão que não conseguia ver o risco. Você ainda nomeia o que aconteceu. Você não nomeia um culpado como a correção.
Essa definição cobre duas reuniões que as pessoas misturam. Uma retro de sprint pode ser sem culpa sobre como a equipe trabalhou. Uma retro de incidente é sem culpa sobre uma falha, e precisa de uma linha do tempo.
O que «sem culpa» significa e o que não significa
Não significa que ninguém preste contas. Alguém ainda é o responsável pela próxima mudança no alerta, no runbook ou no rollout. Significa que a ação é uma mudança no sistema. «Jordan deveria ter mais cuidado» é culpa. «Deploys de produção exigem uma segunda pessoa às sextas depois das 16:00, sob responsabilidade do líder de plantão, revisados em duas semanas» é uma ação sem culpa.
Também não significa uma reunião branda, sem fatos. Uma retro sem culpa sem linha do tempo vira um círculo de sentimentos, e a mesma indisponibilidade volta.
A Diretiva Primária de Norm Kerth é o ponto de partida habitual: com a informação que tinham, as pessoas fizeram o melhor que puderam. Diga isso no início se a sala estiver tensa. Depois passe para a linha do tempo. A frase não é a reunião inteira.
Sem culpa em uma retro de sprint normal
Você não precisa de uma indisponibilidade. Use linguagem sem culpa quando os cartões começam a nomear pessoas:
- Troque «Alex quebrou o build» por «o build ficou vermelho por um dia porque a verificação que falhava não era obrigatória no pull request».
- Troque «produto fica mudando o escopo» por «três histórias mudaram os critérios de aceite depois que o desenvolvimento começou».
Depois vote e escolha uma mudança no sistema. O resto da pauta é a retrospectiva de sprint normal: cartões em silêncio, uma votação, de uma a três ações.
Como conduzir uma retrospectiva de incidente sem culpa
Conduza isso em poucos dias após o incidente, não na próxima retro de sprint. Convide as pessoas que estavam na resposta, mais um facilitador que consiga interromper a culpa. Mantenha em 45–60 minutos para um incidente.
1. Escreva a linha do tempo antes da reunião (15 minutos, de forma assíncrona)
Uma lista compartilhada, da mais antiga para a mais recente:
- quando o primeiro sinal disparou, ou quando um cliente escreveu
- quando uma pessoa viu
- o que acreditavam que estava acontecendo
- o que mudaram
- quando o impacto parou
Peça a cada pessoa que acrescente os passos que deu. Faça isso por escrito para a reunião não ser um concurso de memória. Cartões anônimos ajudam na linha «o que eu acreditava» se as pessoas esperam punição.
2. Abra a regra (2 minutos)
Diga: não vamos atribuir uma pessoa como a causa. Vamos sair com mudanças em detecção, decisão ou recuperação. Se um nome aparecer, escreva a condição em volta dessa pessoa.
3. Percorra a linha do tempo (15 minutos)
Leia em ordem. Pergunte só: o que sabíamos neste minuto e o que as ferramentas mostravam? Corrija os horários. Não pule ainda para «o que deveríamos ter feito».
4. Encontre as condições contribuintes (15 minutos)
Agrupe as notas em três colunas:
- Detecção: alerta ausente, alerta ruidoso, painel que ninguém abre
- Decisão: runbook errado, responsável pouco claro, duas pessoas fazendo mudanças opostas
- Recuperação: rollback lento, flag travada, mensagem ao cliente atrasada
Essas colunas mantêm a conversa no sistema. Um cartão que só diz um nome não recebe voto.
5. Escolha de uma a três correções (10 minutos)
Cada correção nomeia a condição, a mudança, um responsável e uma data. Prefira uma correção de detecção. Incidentes que não acionam ninguém vão acontecer de novo, por mais cuidadoso que o engenheiro tenha sido.
Envie a linha do tempo e as ações para a equipe. Não arquive o documento onde só quem facilita consegue encontrar. Revise as ações na próxima retro de sprint, nos primeiros cinco minutos.
Linguagem que você pode corrigir na sala
| Culpa | Sem culpa |
|---|---|
| Quem fez o deploy disto? | Que verificação não rodou antes do deploy? |
| Eles deveriam ter sabido | O que o painel mostrava naquele minuto? |
| Erro humano | Qual passo não teve uma segunda olhada, e por que isso era o normal? |
Perguntas frequentes
O que é uma retrospectiva sem culpa?
É uma retrospectiva que trata a falha como uma propriedade do sistema. As pessoas descrebem o que sabiam na hora. As ações mudam alertas, runbooks, revisões ou regras de rollout. O nome de uma pessoa não é a ação corretiva.
Como conduzir retrospectivas de incidentes sem culpa?
Escreva a linha do tempo antes da reunião, proíba «quem causou isto» como resultado, organize as notas em detecção, decisão e recuperação, e saia com uma a três mudanças no sistema com responsável. Mantenha separada da retro de sprint.
Um postmortem sem culpa é a mesma coisa?
Sim para este propósito. Postmortem, revisão de incidente e retrospectiva de incidente são a mesma reunião quando usam uma linha do tempo e recusam a culpa como correção. Uma retrospectiva de sprint é uma reunião diferente, sobre o sprint inteiro.
Comece um quadro grátis e coloque Detecção, Decisão e Recuperação nas colunas. As pessoas participantes podem entrar pelo link sem uma conta.