O modo de falha mais grave não é uma cerimônia mal feita. É uma cerimônia bem feita que não muda nada.

Uma reunião de stand-up pode ser gravada, uma sessão de planejamento pode ser sobrecarregada, e a equipe ainda assim sentirá o atrito e a resistência. A falta de acompanhamento é pior porque parece tudo bem. A retrospectiva acontece, as pessoas são sinceras, post-its são preenchidos, todos concordam com a cabeça — e então o sprint termina e nada muda. Faça isso algumas vezes e você não vai ver raiva; vai ver algo mais silencioso e mais corrosivo. Como um engenheiro colocou no Hacker News: “as retrospectivas permitem que as preocupações sejam expostas, mas, na minha experiência, nada realmente acontece em relação a essas preocupações”. Outro, de forma mais direta: “Nunca vi nada acontecer além de palavras.” Essa é a reclamação mais repetida sobre retrospectivas em qualquer lugar, e não é a reclamação que os conselhos do nosso setor imaginam que seja.

Palavras, e apenas palavras

A visão comum é que as equipes “se esquecem de registrar itens de ação”, então a solução padrão é registrá-los melhor — torná-los SMART, designar um responsável e adicioná-los ao quadro. Isso ignora a verdadeira causa do problema. O problema raramente é que nenhuma ação foi registrada; é que a ação foi registrada, adicionada ao backlog e depois ficou lá para sempre, enquanto a próxima retrospectiva gerava mais três. “Tenho repetido os mesmos itens da retrospectiva de sprint após sprint sem que sejam resolvidos”, diz um relato resignado. “Este post-it não será resolvido. É meio triste.” De acordo com uma pesquisa frequentemente citada, apenas cerca de um terço das equipes conclui consistentemente suas ações da retrospectiva — e os outros dois terços estão aprendendo, sprint após sprint, que a cerimônia produz palavras e apenas palavras. No entanto, é preciso ter cuidado com essas crenças populares: nossos próprios dados primários sobre qual porcentagem das ações da retrospectiva realmente é concluída indicam que a taxa de conclusão está mais próxima de três em cada quatro — e mostram que o comprometimento e a cadência, e não o esforço, determinam essa diferença.

A solução que realmente funciona não é fazer mais ações — é fazer menos. Limite a apenas uma. Uma única melhoria com a qual a equipe se comprometa de verdade, analisada logo no início da próxima retrospectiva antes de qualquer outra coisa acontecer, é melhor do que uma lista de dez que acabam sendo silenciosamente deixadas de lado. Estabeleça muitas ações e metade não será concluída — e a metade que não for concluída ensina à equipe que nada disso importa. Um único item, com responsabilidade definida e data de revisão, fecha o ciclo que uma longa lista deixa aberto. O capítulo por que as retrospectivas falham do nosso guia de retrospectiva aborda como conduzir esse ciclo a partir da própria cerimônia, e a retrospectiva de “marcar caixas” no capítulo Desempenho mostra como fica o vazio antes que a equipe desista completamente.

A válvula de pressão

Mas existe uma versão mais profunda desse vazio, e é justamente essa que os conselhos do nosso setor interpretam de forma equivocada. Às vezes, as ações não acontecem porque a equipe nunca teria capacidade de fazê-las acontecer — já que os verdadeiros problemas estão genuinamente além do alcance da equipe. Orçamento, quadro de funcionários, dependências entre equipes, uma decisão de arquitetura tomada dois níveis acima, um prazo definido pela equipe de vendas. A equipe pode citar esses problemas o dia inteiro. Mas não pode resolver nenhum deles. E assim, a retrospectiva se torna uma válvula de escape: um lugar para desabafar, para que a liderança sinta que a equipe foi ouvida, sem nenhum mecanismo para mudar a situação que está sendo criticada.

vs feedback in Owner Pressure valve input in, nothing out Radiator pushed out to an owner
Uma válvula libera vapor apenas o suficiente para não mudar nada; um radiador repassa o mesmo problema para um proprietário específico. A seção seguinte transforma um no outro.

A afirmação mais contundente a esse respeito vem de um desenvolvedor que escreveu no dev.to, e vale a pena citá-la na íntegra: “a retrospectiva se tornou uma válvula de escape. Uma aparência de voz sem substância de poder.” O mesmo texto aponta algo que deveria deixar qualquer coach desconfortável: “culpar a facilitação é como culpar a caixa de sugestões pelo fato de a gerência não ler as sugestões.” Não é possível resolver um problema de poder apenas por meio da facilitação. E no Hacker News, de forma direta: uma retrospectiva é “uma cerimônia sem propósito real, porque geralmente as questões mais profundas que as pessoas levantam não estão ao alcance do controle daquela equipe” — e, pior ainda, “ela dá à liderança uma desculpa para não resolver os problemas”.

É aqui que a maioria dos conselhos dos fornecedores causa danos reais. A lista padrão de antipadrões diz às equipes para “permanecerem dentro do seu círculo de influência” — parem de levantar questões que não podem mudar. Enquadrado como um problema de disciplina da equipe, esse conselho está totalmente errado. Ele diz à equipe para ignorar o verdadeiro obstáculo e refletir apenas sobre as questões pequenas, seguras e controláveis pela equipe, que é exatamente como uma retrospectiva se transforma em um teatro confortável. Permanecer dentro do seu círculo de influência é um mau conselho quando o que há de mais importante na sala está fora dele.

Irradie para fora, não reprima para dentro

A boa notícia é que o texto canônico já traz a correção — e foi a edição atual que a incluiu. A segunda edição de Agile Retrospectivas (2024), com David Horowitz se juntando a Esther Derby e Diana Larsen, acrescentou um capítulo inteiro sobre questões que estão fora do controle da equipe — o problema ficou grave o suficiente para que a obra de referência se atualizasse. Três de suas ferramentas são o antídoto para a válvula de pressão:

  • Círculos e “Sopa” — classifique cada questão de acordo com quem é o responsável por ela: o que a equipe controla, o que ela pode influenciar e o que está na “sopa” — aquilo a que ela só pode reagir. Essa é a triagem por responsabilidade, e ela substitui o princípio de “permaneça no seu círculo” pelo de “encaminhar cada problema para quem realmente pode agir sobre ele”.
  • Soluções de 15% — para os grandes problemas que estão paralisados, identifique a parte pela qual a equipe pode começar a trabalhar agora, sem precisar da permissão de ninguém. Não a solução completa; os 15% que estão ao nosso alcance. É melhor ganhar impulso com uma fração do que ficar paralisado diante do todo.
  • Radiadores Retrospectivos — tornam as questões escaladas visíveis externamente, em um quadro que a liderança possa ver, com acompanhamento ao longo do tempo. Um radiador é o oposto de uma válvula: uma válvula libera a pressão e a oculta; um radiador divulga o item não resolvido até que alguém com poder para resolvê-lo o faça. Escalem os itens marcados em vermelho, indicando o nome responsável.

Essa é a linha rígida que a pesquisa aponta, e ela tem respaldo no cânone: triagem por propriedade, escalonamento de itens vermelhos por nome e data, irradiar em vez de desabafar. Uma retro que segue isso é honesta em relação ao poder. Uma retro que ignora isso é uma válvula de pressão com um facilitador.

O importante é aprender, não a lista de tarefas

A última reformulação fecha o ciclo de todo o modo. A segunda edição também altera o próprio critério de sucesso — passando das ações a serem realizadas para a aprendizagem. A posição da segunda edição — e é um alívio ouvir isso vindo da fonte oficial — é que uma retrospectiva sem uma ação a ser tomada não é um fracasso se a equipe aprendeu algo. A unidade de mudança passa a ser um experimento — uma hipótese que você testa com uma data de revisão — em vez de uma tarefa pendente que apodrece no backlog. “Acreditamos que trabalhar em pares na implantação reduzirá nossa taxa de reversão; vamos tentar isso por dois sprints e verificar” é um experimento. “Melhorar as implantações” é um post-it que vai para o lixo.

Action item “Improve deploys” backlog words, and only words Experiment EXPERIMENT We think X… Try — 2 sprints Review ▸ a date learned a change you’re running Judge a retro by what it learns, not the to-dos it lists.
Uma tarefa como “melhorar as implantações” fica parada no backlog sem ninguém se responsabilizando por ela; a mesma intenção, quando enquadrada como um experimento — uma hipótese com uma data de revisão —, torna-se uma mudança que a equipe está realmente colocando em prática.

Isso também dá importância a um custo que nunca aparece nas listas de antipadrões: o desgaste emocional de uma sessão dedicada exclusivamente ao desabafo. Como disse um participante, uma retrospectiva pode ser “mais de uma hora sentado ali, basicamente ouvindo outras pessoas reclamarem de coisas, o que me deixa desanimado”. Uma retrospectiva dedicada apenas ao desabafo não apenas deixa de resolver os problemas — como também sobrecarrega as pessoas que absorvem as reclamações. A solução não é proibir os sentimentos; é dar a eles uma saída: transformar os itens em vermelho em experimentos assumidos, com prazo definido e divulgados, e assim a hora deixa de ser um espaço onde a frustração simplesmente circula.

Esse é o caminho para sair do vazio e do guia. Faça o ciclo curto o suficiente para fechá-lo, faça a triagem com honestidade suficiente para escalar o que a equipe não consegue resolver e avalie o aprendizado em vez de contar ações — porque a franqueza que não muda nada acaba deixando de ser franqueza. Os quatro modos — Desempenho, Poder, Sobrecarga e o Vazio — são, no fim das contas, a mesma pergunta feita de quatro maneiras: essa cerimônia está cumprindo seu papel ou apenas representando-o?

Perguntas frequentes

O que você faz quando os mesmos problemas surgem em todas as retrospectivas?

Identifique por que elas se repetem, pois duas falhas diferentes podem parecer idênticas por dentro. Se a ação foi registrada, mas nunca assumida como responsabilidade, ela fica estagnada no backlog enquanto a próxima retrospetiva acrescenta mais três — limite a um item assumido com data de revisão e inicie a próxima retrospetiva verificando-o. Se a questão continuar voltando porque está genuinamente fora do controle da equipe, relistá-la nunca vai funcionar: faça uma triagem com base em quem é o responsável e encaminhe-a para os superiores, indicando nome e data, em vez de desabafar novamente.

O que você faz quando o verdadeiro problema está fora do controle da equipe?

Não incentive a equipe a levantar problemas menores — é assim que uma retrospectiva se transforma em teatro. Classifique cada problema de acordo com quem é o responsável por ele; em seguida, encaminhe os problemas críticos para os níveis superiores, indicando um nome e uma data, e torne-os visíveis no quadro de retrospectiva para que não sejam discretamente ignorados. Permanecer dentro do seu círculo de influência é um mau conselho quando isso significa ocultar o verdadeiro obstáculo.

Como fazemos para que as tarefas retrospectivas sejam realmente concluídas?

Limite a apenas uma. Uma única melhoria com a qual a equipe se comprometa de verdade, analisada logo no início da próxima retrospectiva antes de qualquer outra coisa, é melhor do que uma lista de dez que acabam sendo discretamente deixadas de lado. Designe um responsável e uma data para revisão, e trate isso como um experimento com uma hipótese, em vez de uma tarefa mais na lista.

Uma retrospectiva precisa de uma ação a ser tomada?

Não — e insistir que sim faz parte do problema. A segunda edição de “Agile Retrospectives” reformula o critério de sucesso como aprendizado, e não como itens de ação: uma retrospectiva em que a equipe realmente compreendeu algo novo não é um fracasso só porque não gerou uma lista de tarefas. Faça experimentos com os quais você possa aprender, não tarefas pelas quais você vai se sentir culpado.

Leituras relacionadas