Retrospectivas que geram ação real

Quantas retrospectivas seu time fez onde as mesmas ações se repetem sprint após sprint, sem nunca serem implementadas? Se a resposta é “muitas”, este artigo é para você.

Por que retrospectivas falham

• Muitas ações — time define 5-6 melhorias, consegue fazer 1
• Ações vagas — “melhorar comunicação” não é acionável
• Sem dono — ninguém é responsável por executar
• Sem follow-up — nadie revisa se a ação foi implementada
• Falta de segurança psicológica — o time não fala a verdade com medo de retaliação

Formato eficaz: menos é mais

Regra de ouro: no máximo 2 ações por retrospectiva

Menos ações significam mais chance de execução. É melhor implementar 2 mudanças por sprint do que listar 10 que nunca saem do papel.

Estrutura de ação acionável

Cada ação deve ter:

• O quê — ação específica e mensurável
• Quem — responsável por garantir a execução
• Quando — deadline dentro do sprint atual
• Como medir — métrica ou sinal de que funcionou

Exemplo ruim: “Melhorar a qualidade do código” Exemplo bom: “João vai criar e implementar um checklist de PR até quarta. Medir: 100% dos PRs do próximo sprint terão o checklist preenchido”

Técnicas de retrospectiva para variar

1. Start, Stop, Continue (clássica)

Simples e funcional, mas limitada. Use quando o time precisa de uma retrospectiva rápida.

2. 4 Ls — Liked, Learned, Lacked, Longed for

• Liked: o que gostamos no sprint?
• Learned: o que aprendemos?
• Lacked: o que faltou?
• Longed for: o que desejamos para o próximo?

3. Sailboat (Barco à Vela)

• Vento (impulsores): o que nos empurrou para frente?
• Âncora (freios): o que nos segurou?
• Recifes (riscos): o que pode dar errado?
• Ilha (objetivo): para onde estamos indo?

4. Happy, Sad, Confused

Cada membro coloca post-its em três categorias. Boa para times novos ou após sprints conturbados.

5. Dados primeiro, opiniões depois

Antes de abrir discussão, apresente dados do sprint: velocidade, bugs, estimativas vs. real. Isso ainda o debate objetivo em vez de subjetivo.

Segurança psicológica

Sem ela, a retrospectiva é teatro. Para criar segurança:

• Anônimo quando necessário — use ferramentas que permitam input anônimo
• Facilitador neutro — Scrum Master, não o gerente do time
• Sem retaliação — o que é dito na retrospectiva fica na retrospectiva
• Líder vulnerável — quando o tech lead admite erros, o time se sente seguro para fazer o mesmo

Follow-up: o passo esquecido

No início da próxima retrospectiva:

1. Revise as ações do sprint anterior — foram feitas? Funcionaram?
2. Celebre as implementadas — reconhecimento motiva
3. Descarte as inviáveis — se não foi feita em 2 sprints, provavelmente não vai ser

Conclusão

Retrospectivas que geram ação real são foco, concretas e com follow-up. Se seu time tem a sensação de “mais uma retrospectiva igual às outras”, provavelmente falta especificidade nas ações ou comprometimento com o follow-up. Comece com 1-2 ações por sprint e construa o hábito de executar o que é decidido.