Retrospetivas de Sprint que Realmente Impulsionam Mudança
Se a retro da tua equipa produz as mesmas queixas em cada sprint, não tens uma retrospetiva — tens uma sessão de desabafo. Já participei em centenas delas. O padrão é consistente: post-its, temas, votos, uma discussão de 10 minutos, e depois nada acontece. Duas semanas depois, os mesmos problemas reaparecem. A equipa deixa de acreditar que as retros podem mudar algo, e eventualmente alguém sugere cancelá-las.
A retro é a cerimónia mais valiosa em qualquer processo ágil. É a única reunião explicitamente concebida para a equipa melhorar a si própria. Quando funciona, compõe — pequenas melhorias a cada sprint que somam uma equipa fundamentalmente melhor ao longo de trimestres. Quando falha, a equipa estagna.
Por Que a Maioria das Retros Falha
Sem acompanhamento nos itens de ação. O principal assassino. A equipa concorda numa ação, ninguém é responsável por ela, e na próxima retro está esquecida. Após três ciclos, a equipa aprende que os compromissos de retro não significam nada.
Ficar ao nível dos sintomas. "Os deployments são lentos" aparece num post-it. A equipa concorda "devíamos tornar os deployments mais rápidos" e segue em frente. Mas a pipeline de CI está inchada? Há um passo de aprovação manual? Os testes são instáveis? Sem aprofundar, a ação é vaga e ninguém sabe o que fazer.
As vozes mais altas dominam. Duas ou três pessoas fazem 80% da conversa. Os engenheiros mais silenciosos — frequentemente com as observações mais aguçadas — ficam calados porque o formato não lhes dá espaço.
Mesmo formato todas as vezes. "O que correu bem / o que não correu / o que melhorar" está bem para as tuas primeiras retros. Após seis meses, está ultrapassado. O tédio mata o envolvimento.
Os 5 Porquês: Chegar às Causas Raiz
A técnica de retro mais poderosa é os 5 Porquês — originalmente da Toyota, mas traduz-se perfeitamente para equipas de software. Quando alguém levanta um problema, continua a perguntar "porquê?" até chegares à causa raiz.
Exemplo:
- "Tivemos uma interrupção em produção na quarta-feira." — Porquê?
- "Uma migração de base de dados foi executada durante o tráfego de pico." — Porquê?
- "Não tínhamos uma política sobre quando executar migrações." — Porquê?
- "Ninguém tinha pensado nisso — o tráfego nunca tinha sido alto o suficiente para importar." — Porquê?
- "Não temos uma checklist de prontidão para deploy." — Causa raiz.
O item de ação não é "não executar migrações durante o tráfego de pico." Isso é um penso rápido. A ação é "criar uma checklist de prontidão para deploy." Isso é uma correção sistémica.
Um Formato que Funciona
Passo 1: Revê os Itens de Ação do Último Sprint (5 minutos)
Começa cada retro a rever os itens de ação anteriores. Fizemo-los? Se não, porquê? Este único passo cria responsabilidade e sinaliza que os compromissos são reais. A regra: Se uma ação não foi completada, é re-comprometida com um responsável claro ou explicitamente abandonada. Nada fica pendente mais de dois sprints.
Passo 2: Brainstorming Silencioso (5 minutos)
Todos escrevem observações de forma independente. Sem falar. O silêncio previne a ancoragem onde o primeiro orador define o enquadramento. Roda os prompts para manter o frescor:
- "O que devíamos começar / parar / continuar a fazer?"
- "Onde nos sentimos bloqueados? Onde nos sentimos em fluxo?"
- "Se pudéssemos mudar uma coisa sobre como trabalhamos, o que seria?"
Passo 3: Agrupa e Vota (5 minutos)
Agrupa observações em temas. Voto por pontos. Escolhe os 2-3 principais tópicos — não 5, não 7. Tentar cobrir tudo significa cobrir nada bem.
Passo 4: Aprofundamento com 5 Porquês (15 minutos)
Para cada tópico, realiza uma discussão estruturada. O facilitador continua a perguntar "porquê?" e previne culpas ou tangentes. Regra fundamental: Não nomear indivíduos. "O processo de deploy é lento" é válido. "O João atrasa code reviews" não é.
Passo 5: Compromete-te com Ações (10 minutos)
Cada ação deve ter:
- Um responsável. Uma pessoa específica, não "a equipa."
- Uma definição de pronto. Não "melhorar os deployments" mas "adicionar fase de testes paralelos para reduzir o tempo da pipeline para menos de 10 minutos."
- Um prazo. Normalmente "até à próxima retro."
Limita a 2-3 ações. Duas ações completadas por sprint é melhor do que cinco abandonadas.
Facilitadores Rotativos
Não deixes a mesma pessoa gerir todas as retros. Quando o tech lead facilita sempre, a dinâmica calcifica. Rota entre a equipa — sim, incluindo os engenheiros mais silenciosos. Fornece um guia simples: o formato acima, caixas de tempo e opções de prompt. A maioria das pessoas é melhor facilitadora do que espera.
O trabalho do facilitador: Gerir o tempo. Garantir que todos falam. Perguntar "porquê?" quando o grupo para nos sintomas. Anotar os itens de ação com responsáveis e prazos.
Criar Responsabilidade
A retro tem 40 minutos. O sistema de responsabilidade é o que faz esses minutos importar.
Torna os itens de ação visíveis. Coloca-os no quadro de projeto da equipa ao lado do trabalho regular. Se a tua equipa usa Jira ou Linear, as ações de retro são tickets no sprint atual. A melhoria de processo não é crédito extra — é trabalho regular.
Faz check-in a meio do sprint. Uma menção de 2 minutos no standup: "Verificação rápida — Sara, como está a melhoria da pipeline de CI?" Isto sinaliza que os compromissos da equipa para consigo própria importam.
Acompanha a taxa de conclusão. Se a tua equipa completa 80% das ações de retro, o processo está a funcionar. Abaixo de 50% significa que as ações são demasiado ambiciosas, demasiado vagas, ou não estão priorizadas.
Quando a Confiança Está Danificada
Se a tua equipa suportou meses de retros ineficazes, acham que é tudo uma perda de tempo. Reconstrói a confiança com vitórias rápidas. Escolhe um problema pequeno e concreto que a equipa possa resolver dentro do sprint. "O nosso template de PR está em falta uma secção de plano de testes." Corrige-o. Mostra o resultado na próxima retro. Após três sprints de ações completadas, a crença regressa. Essa crença é tudo.
Na Conectia, os engenheiros sénior que colocamos em equipas de clientes trazem experiência de múltiplas equipas de alto desempenho. Quando um engenheiro já viu o mesmo bottleneck de deploy resolvido de três formas diferentes em três empresas diferentes, o seu contributo na retro vale mais do que outra ronda de brainstorming do zero.
Precisas de engenheiros que trazem maturidade de processo juntamente com competências técnicas? Fala com um CTO — os nossos engenheiros sénior LATAM fortalecem tanto a tua base de código como as tuas práticas de engenharia.
