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 confiável, 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, não é. Catalogamos em outro lugar os dez antipadrões comuns em retrospectivas, 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. Se a facilitação for realmente o seu problema, a solução está na realização de retrospectivas eficazes, 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 serem levantados (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 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 da 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 o dever, 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 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. 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. As “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 é o que chamamos de “acumular 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.
• Tenha cuidado ao introduzir métricas. Dados objetivos (velocidade, tempo de ciclo) têm seu lugar em uma retrospectiva, mas, no momento em que a velocidade se torna uma meta pela qual a equipe é avaliada, você cria um ciclo vicioso de aumento contínuo da velocidade, e as pessoas passam a otimizar o número em vez de dizer a verdade. Esse é o modo de falha 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 que diz respeito à reclamação mais recorrente em todo o debate: “As retrospectivas permitem que as preocupações sejam expostas, 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 do tipo ‘dia da marmota’ são vividas 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 da retrospectiva 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 a sabedoria popular 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: segundo 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 não for feito.

Em segundo lugar, pare de tratar o item de ação como o objetivo em si. Essa é a reformulação apresentada na 2ª edição de Agile Retrospectives, 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ída”, 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 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, no livro 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 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 abertamente. 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; isso 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, a crítica que o grupo do “nunca pule a retrospectiva” descarta com muita rapidez: as retrospectivas 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 standup, de 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 retrospetivas por ano em uma equipe madura não são uma virtude. A mesma reclamação aparece em escala organizacional na pesquisa sobre a carga de reuniões, onde a proporção de reuniões que as pessoas dizem que poderiam ter dispensado é medida, em vez de estimada.

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 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 os antipadrões de Standups e a falta de acompanhamento em nosso guia de campo “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 online de retrospectiva 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 (quadro de funcionários, 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ê encaminha o problema para instâncias superiores, de forma oficial. Classifique as questões entre o que a equipe controla, o que ela pode influenciar e o que ela apenas pode sofrer (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 custos para a 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 reuniã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 bem definida. Reformule a meta. 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 tarefa a ser realizada, mas é real. Encaradas como um ritual de aprendizado, em vez de uma fábrica de tarefas, elas conquistam seu espaço.