A retrospectiva do seu time é uma perda de tempo? Provavelmente sim.
Toda sexta-feira, o time se reúne. Abre o Miro ou o FunRetro. Coloca post-its no que foi bom, no que foi ruim e no que pode melhorar. Discute por 30 minutos. Agradece. E volta para as mesas. Na segunda-feira, nada muda.
Se isso descreve a retrospectiva do seu time, ela é, sim, uma perda de tempo. Não porque a cerimônia é inútil, mas porque vocês estão fazendo errado.
O propósito real da retrospectiva
A retrospectiva existe para uma coisa: gerar melhoria contínua mensurável. Não é terapia de grupo. Não é sessão de desabafo. Não é momento de celebrar conquistas (isso pode ser feito em outros contextos). É um espaço protegido para o time identificar o que não está funcionando e decidir o que vai mudar.
Segundo o Scrum Guide, a retrospectiva é o evento onde o time planeja maneiras de aumentar a qualidade e a eficácia. Se a sua retro não gera ações que aumentam qualidade ou eficácia, ela não está cumprindo o propósito.
Por que a maioria das retros falha
Três motivos principais. Primeiro, falta de segurança psicológica. Se as pessoas têm medo de falar o que realmente pensam, os post-its serão genéricos e inofensivos. "Melhorar a comunicação" aparece em toda retro. Mas ninguém diz "o João não responde as mensagens e isso atrasa todo mundo" porque tem medo da reação.
Pesquisa do Google (Projeto Aristóteles) identificou que segurança psicológica é o fator número um que diferencia times de alta performance. Se o time não se sente seguro para ser honesto, a retro será um teatro.
Segundo, falta de ações concretas. Discutir problemas sem definir o que vai mudar é catarseie, não gestão. Toda retro deveria terminar com no máximo três ações, cada uma com um responsável e uma data de revisão.
Terceiro, falta de acompanhamento. Se a retro da sprint 10 identificou três ações e na sprint 11 ninguém verificou se foram executadas, o time aprende que a retro não tem consequência. E quando não tem consequência, perde relevância.
Como fazer uma retro que funciona
Comece revisando as ações da retro anterior. Foram executadas? Tiveram efeito? Se não, por quê? Esse accountability é o que dá credibilidade ao processo.
Depois, use uma estrutura focada. Eu prefiro "O que nos impediu de entregar mais valor?" como pergunta central. É mais focada do que "o que foi bom/ruim" e direciona a conversa para ações práticas.
Defina ações com o formato SMART: específicas, mensuráveis, alcançáveis, relevantes e com prazo. "Melhorar a comunicação" não é SMART. "Criar um canal dedicado para decisões de arquitetura e responder em até 4 horas úteis" é.
A retro é o motor de evolução do time. Quando funciona, o time melhora a cada sprint. Quando não funciona, o time repete os mesmos erros indefinidamente. A diferença está em três coisas: segurança para falar, ações concretas e acompanhamento rigoroso.