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. Depois disso, nada muda em relação à forma como o trabalho realmente é realizado. Faça isso quarenta vezes por ano e você não terá criado um hábito de melhoria. Você criou o 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 consistente, palavras e apenas palavras.

O conselho padrão trata uma retrospectiva malsucedida como um problema de facilitação: varie o formato, defina ações mais SMART, inclua um quebra-gelo. Às vezes, esse é o problema. Geralmente, porém, 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 contorna, pois são elas que fazem com que engenheiros experientes considerem as retrospectivas uma perda de tempo: um problema de poder e um problema de acompanhamento. Nenhuma atividade de quebra-gelo resolve esses problemas. Se a facilitação for realmente o seu problema, a solução está em como conduzir retrospectivas eficazes, e não aqui.

O estilo retrô 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 registrar itens de ação. 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 alcance da equipe para serem resolvidos. Como um engenheiro colocou de forma direta 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 estão fora do poder de controle daquela equipe”. Outro, no mesmo tópico: “Isso dá à liderança uma desculpa para não resolver as coisas ou não ouvir, porque a retrospetiva é supostamente o espaço para desabafar.”

Essa é a armadilha. A retrospectiva se transforma em uma válvula de pressão: 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”) acaba, discretamente, se alinhando ao sistema nesse caso. Ele orienta a equipe a esconder 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. O objetivo do anel externo não é “ignore isso”. É a base para um encaminhamento para instâncias superiores.

Nem tudo se agrava, e nem tudo é sem esperança. Soluções de 15%, a técnica das Estruturas Libertadoras para identificar 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 como 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 é acumular feedback: comentários sinceros que são guardados para serem usados contra você mais tarde, e a maneira mais rápida de arruinar 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 for dito fica restrito à sala. Somente as ações que a equipe decidir 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 o item que realmente precise dele.
• Tenha cuidado ao introduzir métricas. Dados objetivos (velocidade, tempo de ciclo) têm lugar em uma retrospectiva, 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 falha no acompanhamento do movimento e a reestruturação que a corrige

Suponhamos que os problemas de energia e segurança estejam resolvidos. As retrospectivas ainda falham no ponto mais repetido em todo o debate: “As retrospectivas permitem que as preocupações sejam expressadas, mas nada realmente acontece a respeito delas”. Ou, de forma mais direta: “Nunca vi nada acontecer além de palavras”. O tom de resignação disso (“esse ponto pendente não será resolvido”) é como as retrospectivas do tipo “dia da marmota” são percebidas por dentro. Não é imaginação: o número que todos repetem, um dado comumente citado de que apenas cerca de um terço das equipes conclui consistentemente suas ações de retrospectiva, acaba exagerando o pessimismo. Medimos quantas ações retrospectivas são realmente concluídas em centenas de milhares de ações reais: a taxa de conclusão está mais próxima de três em cada quatro, e a cadência e o senso de responsabilidade determinam de que lado dessa lacuna uma equipe se situa. O que o folclore acerta é a forma do fracasso. Uma ação pela qual ninguém se responsabiliza, sem prazo definido, em uma equipe sem ritmo, é aquela que é escrita no quadro branco e apagada.

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

Primeiro, pare de tentar resolver tudo. Quanto mais longa for a lista, pior será o desempenho de cada item nela: em nossos dados, as retrospetivas que terminam com dez ou mais ações concluem cerca de 56% delas, contra cerca de 79% nas retrospetivas que terminam com uma a três. Limite-se a uma melhoria com a qual a equipe se comprometa de verdade, inclua-a no trabalho do próximo sprint em vez de deixá-la no quadro e comece cada retrospectiva revisando a única coisa 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 “Mad/Sad/Glad” por um veleiro é apenas maquiagem se o acompanhamento for negligenciado.

Em segundo lugar, pare de tratar o item de ação como o objetivo principal. Essa é a nova perspectiva apresentada no livro Agile Retrospectives, 2ª edição para a qual toda a categoria está caminhando. 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 por um experimento: uma hipótese a ser testada (“se trabalharmos em pares na história de alto 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 rotineira a ser concluída e se torna uma mudança que você está realmente implementando. Johanna Rothman já vinha fazendo essa mesma substituição muito antes de ela se tornar um padrão nas retrospectivas, em Create Your Successful Agile Project: um item, conduzido como um experimento, com o próximo bloco de trabalho da equipe estruturado para incluí-lo.

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

Um fracasso mais discreto: aquela reunião retro 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 faz diferença. É fácil interpretar isso como uma equipe desmotivada. Mas 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ão é um custo real, não uma desculpa

Por fim, há uma crítica que o grupo que defende “nunca pular a retrospetiva” descarta com muita 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. Isso se soma à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 elas têm razão. Cinquenta retrospectivas por ano em uma equipe madura não são uma virtude.

A solução 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 fica repetindo sempre as mesmas conversas superficiais está indicando que o ritmo está errado, não que a reflexão seja inútil. Passe para retrospetivas quinzenais ou realize-as em função de eventos (após um lançamento, após uma interrupção no serviç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, dê continuidade a uma ação concreta e ajuste o ritmo adequadamente, e a retrospectiva deixará de ser uma válvula de escape. Ela se tornará aquela hora do sprint em que a equipe realmente muda sua forma de trabalhar, 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 retrospetiva não tem como encaminhá-las para lugar algum. O quadro fica repleto de problemas que a equipe não consegue resolver sozinha (quadro de funcionários, dependências, um pipeline de implantação com falhas), e todos vão embora 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ê encaminha o problema, de forma oficial. Classifique as questões 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 (um “Retrospective Radiator”) 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 prejuízos à carreira. Os desenvolvedores relatam rotineiramente que comentários retrospectivos 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 fica restrito à sala e que apenas as ações acordadas saem 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 bem definida. Reformule 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 (revelando tensões logo no início, mantendo a coesão da equipe) que nunca aparece como uma ação a ser realizada, mas é real. Consideradas um ritual de aprendizado, em vez de uma fábrica de tarefas, elas conquistam seu espaço.