Nulo: quando a cerimônia não muda nada

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 stand-up pode ser gravada, uma sessão de planejamento pode ser sobrecarregada, e a equipe ainda assim sentirá atrito e resistência. A falta de acompanhamento é pior porque tudo parece bem. A retrospectiva acontece, as pessoas são sinceras, post-its são preenchidos, todos concordam com a cabeça. Então o sprint termina e nada muda. Faça isso algumas vezes e você não vai gerar raiva; vai gerar 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, 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 conclusão está mais próxima de três em cada quatro e mostram que o senso de responsabilidade e a cadência, e não o esforço, determinam essa lacuna.

A solução que realmente funciona não é aumentar o número de ações. É reduzi-lo. 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. Esse conselho não é novo: Johanna Rothman recomendou um único item, tratado como um experimento e incorporado ao próximo bloco de trabalho da equipe, em Create Your Successful Agile Project. Se você definir muitos pontos de ação, 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 responsável definido 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 durante a cerimônia, e a retrospectiva do tipo “marcar caixinhas” 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: os verdadeiros problemas estão, de fato, 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 exemplos o dia inteiro. Mas não consegue 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 aquilo sobre o qual se está desabafando.

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 dá para 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 estão fora do controle daquela equipe”. Pior ainda: “isso 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” (pararem 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 — e é exatamente assim que 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 incorporou. 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 escape:

• Círculos e “Sopa”: classifique cada problema de acordo com quem é o responsável por ele, separando 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 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 estagnados, 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 avançar em 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 responsável.

Essa é a linha rígida que a pesquisa aponta, e ela tem respaldo oficial: triagem por propriedade, escalonamento de itens vermelhos por nome e data, disseminação em vez de desabafo. 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 muda o próprio critério de sucesso, passando das ações a serem realizadas para a aprendizagem. Sua posição (e é um alívio ouvir isso vindo da fonte oficial) é que uma retrospectiva sem uma ação a ser realizada 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 que fica acumulada no backlog. “Acreditamos que trabalhar em pares na implantação reduzirá nossa taxa de reversão; vamos tentar por dois sprints e verificar” é um experimento. “Melhorar as implantações” é um post-it que acaba no esquecimento.

Isso também dá o devido valor 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 de mau humor”. Uma retrospectiva dedicada apenas ao desabafo não apenas falha em 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 aquela 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 sendo realizada?

Perguntas frequentes

O que você faz quando as mesmas questões surgem em todas as retrospectivas?

Identifique por que elas se repetem, pois duas falhas diferentes podem parecer idênticas quando vistas por dentro. Se a ação foi registrada, mas nunca assumida como responsabilidade, ela fica parada no backlog enquanto a próxima retrospetiva acrescenta mais três. Limite a um único item assumido com uma 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 a triagem de acordo com quem é o responsável e encaminhe 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 silenciosamente abandonadas. 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 do livro “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.

Leitura relacionada

• Poder: quando a autoridade se apropria da cerimônia. Por que as questões que valem a pena levantar estão, com tanta frequência, além do alcance da equipe.
• Apresentação: a cerimônia que você realiza para o público. Aquele estilo retrô de “marcar presença”, antes que a equipe desista disso.
• Como criar um espaço psicologicamente seguro. Sinceridade que tem para onde ir.
• A Diretriz Principal retrospectiva. A norma que garante a integridade da sala.
• A retrospectiva de sprint (a cerimônia). Onde a retrospectiva se encaixa no ciclo e o ciclo que ela vem para encerrar.
• Glossário do teatro ágil. Definição dos quatro modos de falha identificados.