Por que as retrospectivas fracassam (e como fazer com que a sua seja significativa)

Sua equipe realiza uma retrospectiva a cada sprint. As pessoas aparecem, colam seus post-its, concordam com duas ou três ações a serem tomadas e vão embora. Então, nada muda em relação à forma como o trabalho realmente é feito. Faça isso quarenta vezes por ano e você não terá criado um hábito de melhoria — terá criado um hábito de falar sobre melhoria. Esse é o tipo de falha que quase ninguém menciona: não é um formato ruim, mas um ritual que produz, de forma confiável, palavras e apenas palavras.

O conselho padrão trata uma retrospectiva malsucedida como um problema de facilitação — alternar o formato, definir ações mais SMART, incluir um quebra-gelo. Às vezes, esse é o problema. Normalmente, não é. Catalogamos os dez antipadrões de retrospectiva mais comuns em outro artigo, e vale a pena corrigi-los. Este capítulo aborda as duas falhas que a lista gentilmente evita mencionar, pois são elas que levam engenheiros experientes a considerar as retrospectivas uma perda de tempo: um problema de poder e um problema de acompanhamento. Nenhuma atividade de quebra-gelo resolve esses problemas.

O retorno ao passado que não muda nada, porque o time não consegue

Esta é a crítica mais profunda às retrospectivas, e aquela que nosso próprio post sobre antipadrões interpreta de forma equivocada. Quando um desenvolvedor diz “nunca acontece nada”, geralmente não quer dizer que a equipe se esqueceu de definir ações a serem tomadas. O que ele quer dizer é que os problemas que valem a pena levantar — número de funcionários, dependências entre equipes, um pipeline de implantação que leva quarenta minutos, um prazo definido três níveis acima — estão de fato fora do poder da equipe para resolver. Como um engenheiro colocou claramente no Hacker News, uma retrospectiva pode se tornar “uma cerimônia sem propósito real, porque geralmente as questões mais profundas que as pessoas levantam não estão ao alcance dessa equipe”. Outro, no mesmo tópico: “Isso dá à liderança uma desculpa para não resolver as coisas ou não ouvir, porque a retrospectiva é supostamente o espaço para desabafar.”

Essa é a armadilha. A retrospectiva se transforma em uma válvula de escape — a equipe tem a oportunidade de se expressar, justamente para que nada precise mudar. As pessoas desabafam, a liderança sente que cumpriu sua obrigação, e a causa subjacente permanece intocada. Culpar o facilitador por isso é, como dizia o ensaio de um desenvolvedor, “como culpar a caixa de sugestões pelo fato de a gerência não ler as sugestões”. Nenhuma quantidade de analogias do tipo “veleiro versus estrela-do-mar” dará a uma equipe a autoridade para resolver um problema para o qual ela nunca recebeu autoridade para resolver.

Nosso antigo conselho — “pare de se concentrar em coisas fora do seu círculo de influência” —, discretamente, se alinha ao sistema neste caso. Ele orienta a equipe a ocultar o verdadeiro obstáculo para manter a conversa tranquila. Adote, em vez disso, uma postura mais firme. Classifique cada problema de acordo com quem realmente é responsável por ele: o que a equipe controla, o que ela pode influenciar e o que ela apenas pode sofrer. Essa é a atividade “Circles and Soup” do livro Agile Retrospectives (2ª ed.) de Esther Derby e Diana Larsen — e o objetivo do anel externo não é “ignorar isso”. É a base para uma escalação.

Nem tudo se agrava, e nem tudo é sem esperança. Soluções de 15% — a técnica das Estruturas Libertadoras que consiste em encontrar a menor mudança que a equipe pode fazer sem precisar da permissão de ninguém — mantém o ímpeto no anel de influência enquanto os grandes obstáculos vão sendo superados. Mas a retrospectiva honesta se recusa a fingir que o anel externo é culpa da equipe.

O feedback que é guardado e usado contra você

Agora, a parte sobre a qual nenhum fornecedor escreve. As pessoas ficam caladas nas retrospectivas por um motivo mais concreto do que a timidez: ser honesto pode prejudicar a carreira. O medo é específico e se manifesta em histórias reais. Um desenvolvedor descreveu que o feedback da retrospectiva ressurgiu “na minha avaliação anual, onde foi apontado que eu ‘reclamo demais’”. Outro, de forma mais cínica: “eles guardam todas essas reclamações para usar na hora da revisão do seu bônus anual”.

Isso é o acúmulo de feedback — comentários sinceros que são guardados e usados contra você mais tarde — e é a maneira mais rápida de acabar com uma retrospectiva de sprint. O Guia do Scrum descreve a retrospectiva de sprint como a Equipe Scrum inspecionando a si mesma. Leia isso literalmente: a equipe, inspecionando a si mesma. Então, por que a pessoa que assina sua avaliação de desempenho está sentada na sala tomando notas? O silêncio dela já é suficiente — ninguém que controla sua promoção precisa dizer uma palavra para fazer você amenizar o que teria dito de outra forma. O Projeto Aristóteles, do Google, descobriu que a segurança psicológica é o maior indicador da eficácia de uma equipe; a mera presença de um gerente muitas vezes já é suficiente para eliminá-la. (Abordamos os mecanismos no capítulo sobre como construir um espaço psicologicamente seguro.)

Então, identifique o medo e crie uma estratégia para combatê-lo:

• Mantenha a autoridade de promoção fora da sala. Compartilhe as ações acordadas com os superiores, não os cargos. Uma equipe bloqueada pela presença de um gerente não consegue realizar uma retrospectiva transparente, e nenhum truque de facilitação consegue remediar isso.
• Concordo que o que é dito fica restrito à sala. Apenas as ações que a equipe decide divulgar saem de lá. É isso que permite que as pessoas se expressem, para começar.
• Faça do anonimato uma opção para cada ideia, e não um modo permanente. O anonimato equilibra as dinâmicas de poder e traz à tona assuntos delicados; quando usado como uma muleta permanente, ele corrói a confiança que você está tentando construir. Deixe que as pessoas o escolham para as ideias que realmente precisarem dele.
• Tenha cuidado ao introduzir métricas. Dados objetivos (velocidade, tempo de ciclo) têm seu lugar em um retro — mas, no momento em que a velocidade se torna uma meta pela qual a equipe é avaliada, você cria uma armadilha da velocidade, e as pessoas passam a otimizar o número em vez de dizer a verdade. Esse é o modo de falha de poder que transforma a franqueza em desempenho.

A lacuna no acompanhamento — e a reformulação que a corrige

Suponhamos que os problemas de energia e segurança estejam resolvidos. As retrospectivas ainda falham no que diz respeito à reclamação mais recorrente em todo o debate: “As retrospectivas permitem que as preocupações sejam expressadas, mas nada de concreto realmente acontece a respeito delas.” Ou, de forma mais direta: “Nunca vi nada acontecer além de palavras.” O tom de resignação disso — “essa questão não será resolvida” — é como as retrospectivas que parecem o filme ‘O Dia da Marmota’ são vividas por dentro. Não é imaginação: segundo um dado frequentemente citado pela Scrum Alliance, apenas cerca de um terço das equipes conclui consistentemente suas ações de retrospectiva. O restante é escrito no quadro branco e apagado. O lenda popular exagera um pouco o pessimismo, porém — medimos quantas ações da retrospectiva são realmente concluídas em centenas de milhares de ações reais, e a taxa de conclusão está mais próxima de três em cada quatro, sendo que a cadência e o senso de responsabilidade determinam de que lado da lacuna uma equipe se situa.

Duas correções, sendo que a segunda é a mais importante.

Primeiro, pare de tentar resolver tudo. Uma retrospectiva que gera dez ações a serem tomadas não conclui nenhuma delas. Limite-se a uma melhoria com a qual a equipe se comprometa de verdade e comece cada retrospectiva revisando essa única ação da última vez antes de propor qualquer coisa nova. Se ela não tiver sido concluída, essa é a conversa mais útil na sala. Buscar um novo formato é a primeira coisa que as equipes tentam e a menos provável de ajudar — trocar o “Feliz/Triste/Contente” por um veleiro é apenas maquiagem se o acompanhamento não for feito.

Segundo — e essa é a nova perspectiva apresentada na Agile Retrospectives, 2ª edição para a qual toda a categoria está caminhando — pare de tratar o item de ação como o objetivo principal. A principal mudança proposta por Derby, Larsen e David Horowitz é que o aprendizado, e não a conclusão de uma tarefa, é o critério de sucesso. Substitua a ação a ser realizada por um experimento: uma hipótese a ser testada (“se trabalharmos em pares na história de maior risco, reduziremos o retrabalho”), uma data para revisá-la e uma análise honesta do que realmente aconteceu. Uma retrospectiva que não produziu nenhuma ação do tipo “marcar como concluído”, mas que genuinamente ensinou algo à equipe, não é uma retrospectiva fracassada. Essa única mudança dissipa a reclamação de que “nada muda”, porque a meta deixa de ser uma tarefa concluída e se torna uma mudança que você está realmente implementando.

O silêncio não é apatia — é um sinal

Um fracasso mais silencioso: aquela reunião retrospectiva em que duas das oito pessoas falam por cinco minutos e o resto é silêncio total, e nenhum formato ou quadro pré-preenchido que você tente use muda nada. É fácil interpretar isso como uma equipe desmotivada. Geralmente, não é o caso. O silêncio em uma retrospectiva é um sinal, não o problema em si — ele aponta para falta de confiança, um propósito pouco claro ou uma questão de liderança que as pessoas não ousam mencionar em voz alta. O trabalho remoto piora a situação: câmeras desligadas, microfones silenciados, energia baixa.

Não preencha o silêncio com mais perguntas. Mude quem fala primeiro. Faça uma sessão de brainstorming silenciosa e individual antes de qualquer discussão, para que as pessoas escrevam antes de falar — o que protege os introvertidos e aqueles que não querem ser os primeiros a se manifestar em voz alta. Colete contribuições de forma assíncrona com antecedência. Permita que as pessoas contribuam com um post-it sem precisar defendê-lo diante de todos. O objetivo não é uma reunião animada; é obter dados sinceros, e dados sinceros geralmente surgem discretamente.

A taxa de reuniões é um custo real, não uma desculpa

Por fim, a crítica que o grupo do “nunca pule a retrospetiva” descarta com demasiada rapidez: as retrospetivas têm um custo. “É mais uma reunião na minha agenda que pode interromper qualquer concentração profunda em que eu estivesse”, escreveu um desenvolvedor — somada às reuniões de stand-up, planejamento, revisão e refinamento. Em ciclos curtos, a conta fica pesada: equipes com sprints de uma semana descrevem o planejamento e a retrospectiva semanais como “um fardo”, e têm razão. Cinquenta retrospectivas por ano em uma equipe madura não são uma virtude.

A resposta não é pular as retrospectivas; é ajustá-las ao tamanho certo. Uma equipe recém-formada e sob pressão se beneficia de uma retrospectiva a cada sprint. Uma equipe estável que continua tendo sempre a mesma conversa superficial está indicando que a frequência está errada, não que a reflexão seja inútil. Passe para retrospetivas quinzenais ou acione-as por meio de eventos — após um lançamento, após uma interrupção, após um sprint difícil — quando houver realmente algo a ser analisado. A frequência é um ajuste, não um mandamento. (A mesma lógica de sobrecarga se aplica a todas as cerimônias — veja antipadrões de stand-up e o vazio de acompanhamento em nosso guia de campo do Agile Theatre.)

Resolva o problema de energia, proteja a honestidade, leve adiante uma ação concreta e ajuste o ritmo adequadamente, e a retrospectiva deixa de ser uma válvula de escape. Ela se torna aquela hora do sprint em que a equipe realmente muda a forma como trabalha — o que sempre foi o objetivo. Uma ferramenta de retrospectiva online ajuda de uma maneira específica: ela leva adiante cada mudança acordada como uma ação acompanhada, de modo que o acompanhamento perdure além da semana seguinte à reunião.

Perguntas frequentes

Por que nada muda depois das nossas retrospectivas?

Geralmente porque as questões mais importantes estão fora da alçada da equipe, e a retrospectiva não tem como encaminhá-las a lugar algum. O quadro fica repleto de problemas que a equipe não consegue resolver sozinha — falta de pessoal, dependências, um pipeline de implantação com falhas — e todos saem tendo apenas descrito a situação, em vez de mudá-la. A solução é classificar cada item de acordo com quem realmente é o responsável por ele, manter uma única melhoria controlada pela equipe para trabalhar e encaminhar os itens fora do escopo para os níveis superiores, indicando o nome do responsável e uma data, em vez de simplesmente ignorá-los.

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

Você eleva a questão, de forma oficial. Classifique os problemas entre o que a equipe controla, o que ela pode influenciar e o que ela apenas sofre (a atividade dos “Círculos e Sopa” do livro Agile Retrospectives). O conselho genérico diz para ignorar o anel externo e permanecer no seu círculo de influência. É assim que uma retrospectiva se transforma em teatro. Em vez disso, transforme os itens do anel externo em uma solicitação visível — uma “retrospectiva radiadora” — que identifique o obstáculo, o impacto e quem precisa agir, e apresente-a às pessoas que podem resolver a questão. Uma retrospectiva que apenas traz à tona problemas que a equipe já pode resolver é confortável e desonesta.

É seguro ser sincero em uma retrospectiva?

Somente se a honestidade não acarretar custos para a carreira. Os desenvolvedores relatam rotineiramente que comentários de retroalimentação ressurgem em avaliações de desempenho como evidência de que “reclamam demais”. Se a pessoa responsável pelas promoções estiver presente na sala, ou se o que for dito for guardado para mais tarde, as pessoas ficam caladas e dizem que está tudo bem. Proteja a franqueza de forma deliberada. Mantenha os gerentes de linha responsáveis pelas promoções fora da sessão, combine que o que for discutido ficará restrito à sala e que apenas as ações acordadas sairão de lá, e ofereça o anonimato por ideia, em vez de um modo “tudo ou nada”.

As retrospectivas são uma perda de tempo?

Isso acontece quando o único critério de sucesso é uma tarefa concluída, pois a maioria dos sprints não oferece uma situação tão organizada assim. Reestruture o objetivo — uma retrospectiva é bem-sucedida quando a equipe aprende algo que levará para o próximo sprint, mesmo sem uma tarefa marcada como concluída, e quando realiza um experimento honesto em vez de dez tarefas abandonadas. As retrospectivas também realizam um trabalho mais discreto — trazendo à tona tensões logo no início e mantendo a coesão da equipe — que nunca aparece como uma tarefa a ser cumprida, mas é real. Encaradas como um ritual de aprendizado, em vez de uma fábrica de tarefas, elas conquistam seu espaço.