Retrospectiva ágil: o que se gasta quando ela não vira ação

Resumo executivo
– Retro sem ação custa, no mínimo, uma hora de N devs por sprint, mais a energia emocional de falar do problema sem resolvê-lo.
– O framework SMART — dono, métrica, prazo — é o divisor entre cerimônia e melhoria contínua.
– A diferença entre ação vaga e ação SMART aparece na próxima retro, não na atual: a vaga se repete, a SMART se mede.

A cena que todo time reconhece

Quarta-feira, 16h, sala de reunião. Dez pessoas, post-its coloridos, quadro branco com “Start / Stop / Continue”. Aberta a coluna de “Stop”. Alguém escreve: “Comunicação quebrada entre time e produto”. Aplauso tímido. Mais três post-its na mesma linha, em palavras diferentes. Facilitador pergunta: “Quem topa virar isso numa ação?”. Silêncio. Facilitador reformula: “Quem topa?”. Alguém diz “podemos melhorar”. Aplauso final. A retro termina em 47 minutos. A sprint seguinte abre com a mesma queixa, com os mesmos post-its, na mesma coluna. O time gasta uma hora de dez cabeças e sai exatamente do mesmo jeito que entrou.

Esta cena se repete, em média, a cada duas semanas em boa parte dos times ágeis brasileiros. Não é caso isolado — é padrão de operação. Pesquisas de “State of Agile” sucessivas mostram que entre 30% e 45% dos times reportam baixa ou nenhuma execução das ações combinadas em retrospectiva, dependendo do recorte. Quando uma prática cuja única razão de existir é gerar melhoria contínua entrega menos da metade das suas ações, o problema não é a prática. É o que se entende por melhoria contínua dentro dela.

O custo direto da retro sem consequência

O custo de uma retro mal-operada não é simbólico. É planilhável.

Para um time de oito pessoas com custo médio de R$ 120/hora por dev, uma hora de retro custa R$ 960 por sprint. Em 26 sprints anuais, são R$ 24.976 só em tempo de reunião. Some-se a isso o custo de oportunidade: o time não está codando, testando, revisando PR, estudando dívida técnica — está reescrevendo o mesmo post-it. Some-se a energia emocional de falar do problema e perceber, na sprint seguinte, que ninguém fez nada. Some-se a erosão de confiança: cada retro que termina em “vamos melhorar” sem dono, métrica e prazo reforça a ideia de que retro é ritual, não ferramenta. Quando a confiança na cerimônia cai, a próxima retro precisa fazer mais esforço para extrair honestidade do time — porque ninguém acredita mais que falar muda algo.

O pior dos custos não aparece na planilha. Aparece na próxima sprint. A mesma reclamação volta, o time gasta mais 47 minutos reescrevendo o mesmo post-it em palavras diferentes, e a retro seguinte abre com a sensação difusa de que “retro aqui não funciona”. O time não está errado. A retro, operada sem critério, de fato não funciona — funciona como catarse, e catarse não é entrega.

Por que a retro vira ritual, mesmo em times competentes

Não é má intenção. É ausência de critério compartilhado.

Três mecanismos explicam o padrão. Primeiro, evitação de confronto. Ação significa cobrar alguém, e cobrar alguém custa relacionamento. Sem framework explícito que obrigue a nomear dono, o time converge para a versão mais confortável: “vamos todos melhorar”. Todos melhorarem é uma promessa sem custo político, e por isso mesmo sem resultado.

Segundo, ações viram genéricas para não constranger. “Melhorar comunicação” é o exemplo clássico. A frase é verdadeira, é consensual, e é completamente inútil. Não diz quem, não diz como, não diz até quando, não diz como medir. Mas passa pelo filtro do “espaço seguro” porque não aponta ninguém. A frase serve para todos e não compromete ninguém.

Terceiro, ninguém é dono porque ninguém foi nomeado. Sem dono, a ação se dilui. Aparece na primeira daily, some na terceira, reaparece na próxima retro como nova reclamação. O ciclo se retroalimenta: como ninguém foi cobrado, ninguém cobra na próxima; como ninguém cobrou, a ação “fracassou”; como “fracassou”, o time conclui que “comunicação é difícil de melhorar” — e repete a frase genérica. A ironia é que a falha de execução vira evidência de que a ação era difícil, quando o que faltou foi apenas estrutura de execução.

Times maduros não estão imunes. Maturidade ajuda a diagnosticar, mas não substitui critério de saída. Sem framework SMART aplicado de forma forçada, time maduro tira ações vagas, e time imaturo tira ações que somem na primeira interrupção. O framework é o que distingue um time que usa retro de um time que atravessa retro.

O framework SMART forçado: dono, métrica, prazo

George T. Doran publicou o acrônimo SMART em 1981, no artigo “There’s a S.M.A.R.T. way to write management’s goals and objectives”. Originalmente era Specific, Measurable, Assignable, Relevant, Time-bound. A tradução operacional em retro contemporânea tem três campos obrigatórios que precisam ser preenchidos antes da retro fechar:

• Dono. Nome de uma pessoa, não de um time. “O time de backend” não é dono. “Ana” é. Sem nome próprio, a responsabilidade se dilui. A pergunta direta do facilitador deve ser: “Qual nome?”. Se ninguém fala, a ação não sai.
• Métrica. Como vai se saber que funcionou. Não “comunicação melhor” — isso não é métrica. “Zero surpresas em daily” é métrica. “PR review em menos de 4 horas úteis” é métrica. “Três bugs em produção por sprint ou menos” é métrica. Sem métrica, não há como avaliar resultado — só intenção.
• Prazo. Data em que a ação será revisada. Não “próxima sprint” — isso é ambíguo. “Sprint 47 (review dia 18/08)” é prazo. Sem prazo, a ação não tem data de cobrança, e ação sem data não acontece.

A regra operacional é simples: se a ação proposta não tem os três campos preenchidos, ela não entra no quadro. Volta para discussão até que alguém se nomeie como dono, sugira métrica e indique prazo. Isso parece burocrático. É o que faz a retro funcionar.

Caso concreto: a mesma reclamação, dois formatos

O exemplo que aparece em quase todo time: “Melhorar comunicação”.

Formato vago, pós-it na coluna “Stop”:

Melhorar comunicação entre time e produto

Esse post-it é tecnicamente verdadeiro, operacionalmente vazio, e politicamente confortável. Ninguém precisa se expor, ninguém precisa fazer nada, ninguém precisa prestar contas. A ação some na primeira interrupção, volta na próxima retro, e o time vai passar mais dois anos falando que “comunicação precisa melhorar”.

Formato SMART, mesmo problema:

Ação: Daily às 9:30, com a PO presente nos primeiros 5 minutos.
Dono: Bruno.
Métrica: zero decisões em daily que precisem de reunião extra depois.
Prazo: revisar na retro da sprint 47 (dia 18/08).

A diferença entre os dois formatos é a diferença entre confissão pública e plano executável. O segundo formato nomeia, mede, e tem data. Se Bruno não aparecer às 9:30, o time sabe. Se a métrica não melhorar, o time mede. Se na retro da 47 nada mudou, a ação morre — mas morre com evidência, não com retórica. A retro seguinte trata de uma ação que falhou, não de uma sensação difusa.

Como auditar a próxima retro em 5 perguntas

Antes de fechar a próxima retro, aplicar o checklist:

1. Cada ação no quadro tem um nome próprio como dono?
2. Cada ação tem métrica binária ou numérica — “vai saber se funcionou olhando para o quê”?
3. Cada ação tem data de revisão escrita em formato “sprint X, dia Y”?
4. As ações da retro anterior foram revistas no início desta retro? Se não, por quê?
5. Alguma das ações da retro anterior morreu sem cerimônia? O que faltou para ela ter sido executada?

Se a resposta a qualquer dessas perguntas for “não sei” ou “boa pergunta”, a retro tem problema estrutural — não é má vontade do time, é ausência de framework. Corrigir o framework é mais barato do que continuar operando retro como confessionário.

O critério que separa retro útil de retro inútil

Retro é trabalho, não confraternização. A diferença entre as duas coisas cabe em três campos de formulário: dono, métrica, prazo. Sem os três, é catarse — e catarse, em time de engenharia, é o luxo mais caro que existe, porque paga com hora técnica que poderia estar entregando software.

A pergunta que fica para o próximo sprint não é “como foi a retro?”. É: “quantas ações SMART saíram da última retro, e quantas estão executadas?”. Se a resposta for zero em qualquer um dos dois lados, o problema não é a retro. É o que se chama de melhoria contínua dentro dela.

Leitura relacionada

• Planning poker não é estimativa. É política. E tem substituto. — o ponto em comum é “ritual que virou política, não ferramenta”; o argumento é o mesmo, aplicado à retro.
• Sprint de duas semanas é um ciclo de feedback tão lento quanto waterfall — a retro é onde o feedback vira (ou não vira) ação; este post mostra onde a engrenagem trava.
• Seu backlog é 90% dívida técnica disfarçada de feature. — backlog é o cemitério de ações de retro que nunca viraram trabalho real; este post fecha o ciclo explicando por que ações somem.