Poder: quando a autoridade se apropria da cerimônia

Toda cerimônia ágil pressupõe igualdade de condições. O poder surge quando essa igualdade não existe.

O Planning Poker só supera o efeito de ancoragem se ninguém na mesa puder ignorar as cartas. Uma retrospectiva só é segura se a honestidade não acarretar nenhum custo. A velocidade só é uma previsão se ninguém acima da equipe estiver avaliando-a. Remova essas suposições — acrescente um gerente que aprove as promoções, uma métrica que sobe na hierarquia, uma estimativa que se transforma em promessa — e a cerimônia não apenas deixa de funcionar bem. Ela se inverte. Passa a trabalhar contra as pessoas para quem foi criada. Este capítulo aponta as três formas mais marcantes pelas quais isso acontece, pois identificá-las é o primeiro passo para rejeitá-las.

A catraca de velocidade

Comece com o argumento mais contundente de todos: a própria pessoa que inventou os story points se desfez deles. “Gosto de dizer que talvez eu tenha inventado os story points e, se o fiz, peço desculpas agora”, escreveu Ron Jeffries em 2019 — e, especificamente, “acho que comparar equipes com base na qualidade das estimativas ou na velocidade é prejudicial”. Quando o próprio inventor da unidade diz que ela está sendo usada para prejudicar as equipes, o ônus da prova recai sobre quem ainda a utiliza como um indicador de desempenho.

A catraca de velocidade é como esse dano se manifesta. A velocidade deve ser uma autoavaliação interna da equipe — a média móvel dos pontos concluídos, usada para prever quanto tempo levará para concluir o backlog. No momento em que ela deixa de ser uma meta de produtividade, torna-se uma catraca: o número do último sprint é o piso deste sprint, e a única direção em que ela pode se mover é para cima. As equipes não são burras, então respondem da única maneira que o incentivo permite — elas inflacionam os números. Uma história que valia 3 no último trimestre vale 5 neste trimestre; o número sobe, e nada é entregue mais rápido. Até mesmo Mike Cohn, a autoridade pró-pontos, admite esse mecanismo: o menor indício de que as velocidades serão comparadas produz uma inflação gradual e consistente dos pontos.

A base mais sólida para manter a velocidade dentro dos limites é DORA. Uma década de pesquisa sobre o que prediz o desempenho na entrega de software resultou em quatro métricas — frequência de implantação, tempo de ciclo, taxa de falhas nas alterações e tempo de restauração — e a velocidade foi deliberadamente deixada de fora, pois os story points não são comparáveis entre equipes e medem o esforço, não o valor entregue. Portanto, a regra é simples e defensável: faça previsões com a velocidade, mas nunca avalie com base nela. Se alguém de fora da equipe perguntar “sua velocidade está boa?”, a solução está antes do número — a resposta honesta é “o que você está realmente tentando medir?”. Nosso capítulo sobre velocidade mostra como manter a honestidade, e planejamento de velocidade e capacidade mostra como usá-la para a única coisa para a qual ela serve.

Lavagem de orçamentos

A segunda distorção é mais sutil, pois se assemelha à prestação de contas. Lavagem de estimativas é a conversão silenciosa de uma estimativa — um palpite, feito com o mínimo de informação que você jamais terá — em um compromisso, e, em seguida, obrigar a equipe a cumpri-lo como se tivesse assinado um contrato. A suposição é levada para a reunião de planejamento; um prazo é definido; e, quando o prazo não é cumprido, a culpa recai sobre o desenvolvedor por “não ter acertado a estimativa”.

Os profissionais descrevem todo o ciclo de “lavagem” sem precisar que lhes peçam: as estimativas se transformam magicamente em compromissos, e se você não atingir a meta, a culpa é sua. As estimativas são rejeitadas — “isso não pode estar certo, refaça” — até que a equipe apresente qualquer número que faça o prazo bater, momento em que o planejamento se torna uma farsa com uma resposta predeterminada. Há até mesmo uma assimetria reveladora na linguagem: diga “isso vai levar dez dias” e um gerente vai insistir “você tem certeza de que não podem ser nove?”; diga “isso são dez pontos” e, por razões que ninguém consegue defender direito, o mesmo instinto não se manifesta. Os pontos de história foram criados, em parte, para servir de proteção contra exatamente essa pressão — e a “lavagem de estimativas” é a pressão que derrota essa proteção, convertendo os pontos diretamente de volta em uma data.

A abordagem canônica é a de Mike Cohn e é anterior à nossa expressão: separar a estimativa do compromisso. Uma estimativa é uma distribuição de probabilidade; um compromisso é uma decisão que a equipe toma sobre o que está confiante de que pode entregar. Mantenha-os separados, de forma explícita. Preveja um intervalo e identifique as premissas subjacentes a ele. E fique atento ao caso de acumulação — quando escopo, tempo e custo são todos fixados antecipadamente e o trabalho é meramente dividido em sprints de duas semanas, você não tem ágil com estimativas, você tem cascata disfarçada. Dave West, da Forrester, chamou isso de “water-scrum-fall”, e a “lavagem de estimativas” é o seu cerne. Nosso capítulo pontos de história x horas explica por que a conversão é o modo de falha, e não a solução.

Banco de comentários

A terceira distorção é a mais sombria, pois transforma a cerimônia que parece mais segura em um risco. Acúmulo de feedback é quando comentários retrospectivos sinceros são acumulados e discretamente usados contra você mais tarde — em uma avaliação de desempenho, na definição de bônus ou em uma conversa discreta sobre “adequação”. A retrospectiva é apresentada como um espaço seguro para se ser franco. O “armazenamento de feedback” é a constatação de que a franqueza tem uma data de vencimento.

As histórias de conflito são específicas e doem. Um engenheiro descreveu como o feedback negativo voltava à tona na avaliação anual como prova de que ele “reclama demais”. Outro explicou o mecanismo sem rodeios: a gerência acumula todas as reclamações para usá-las contra você na revisão do bônus anual. Esse efeito inibidor nem sequer requer malícia — a pessoa que aprova as promoções não precisa dizer uma palavra na sala. A simples presença dela já é suficiente para transformar comentários sinceros em observações vagas e para ensinar a todos que a atitude mais inteligente é fingir satisfação. Nosso capítulo por que as retrospectivas falham aborda como planejar a sessão para que a honestidade deixe de ter um custo para a carreira.

É aqui que a literatura sobre segurança deixa de ser mera retórica. O trabalho de Amy Edmondson sobre segurança psicológica e o Projeto Aristóteles do Google — dois anos de estudo com 180 equipes — constataram que a segurança psicológica é o mais forte dos cinco fatores identificados — aquele sobre o qual os outros quatro se apoiam. Uma equipe que percebeu que seu feedback está sendo guardado não tem segurança psicológica, por definição, e a retrospectiva que finge o contrário é uma encenação que acarreta risco jurídico. O Guia do Scrum define a retrospectiva como o momento em que a equipe se autoavalia — então, por que o gerente está na sala tomando notas?

Não conte com um herói

Existe um ponto fraco dentro da solução. Essas distorções geralmente são contidas porque alguém sênior — um líder, um gerente de equipe com coragem — protege pessoalmente a equipe: recusa-se a repassar a velocidade para os superiores, reformula as estimativas como previsões e mantém o conteúdo da retrospectiva restrito à sala. Isso funciona, mas apenas enquanto essa pessoa permanecer no cargo. Um escudo não é um sistema. Se a honestidade de suas cerimônias depende da disposição de um único gerente em absorver a pressão, você não tem cerimônias seguras — você tem uma cerimônia temporariamente benevolente, e a farsa recomeça no dia em que essa pessoa se for.

Essa é a diferença entre o Poder como um modo de falha e o Poder como algo fixo. O capítulo sobre segurança psicológica aborda a construção de uma franqueza que não dependa de quem está na sala, e a Diretriz Principal trata da norma que faz com que isso se mantenha. Quando a cerimônia formalizada acaba produzindo nada além de aparências controladas, você chega ao vazio de acompanhamento — o quarto modo, e aquele em que o acúmulo de feedback causa seu dano mais silencioso.

Perguntas frequentes

Como faço para impedir que a gerência use a velocidade contra minha equipe?

Mantenha esse número dentro da equipe. A velocidade é um dado para previsão, não uma métrica de desempenho — a pesquisa da DORA a exclui deliberadamente porque os pontos não são comparáveis entre as equipes. Se um gerente de fora da equipe perguntar se a sua velocidade é boa, a resposta honesta é fazer uma pergunta de volta: o que você está realmente tentando medir? Relate resultados e entregas, não totais de pontos.

O feedback retrospectivo pode ser usado contra mim em uma avaliação de desempenho?

Isso acontece, e o medo é racional — os participantes relatam que comentários sinceros feitos na retrospectiva ressurgem meses depois como uma crítica de que reclamam demais. Isso é o que chamamos de “acumulação de feedback”, e é por isso que existem o anonimato, a exclusão dos gerentes e a “regra de Las Vegas”. Uma retrospectiva em que a franqueza representa um risco à carreira não é psicologicamente segura, e nenhuma técnica de facilitação resolve isso. Corrija a dinâmica de poder, não o texto.

Como faço para evitar que as estimativas se transformem em prazos?

Separe a estimativa do compromisso, em voz alta e de forma deliberada. Uma estimativa é uma probabilidade; um compromisso é uma promessa; confundir uma com a outra e depois exigir que a equipe cumpra é o que quebra a confiança. Preveja um intervalo, especifique as premissas e nunca permita que uma suposição feita em uma reunião de planejamento seja citada como uma data com a qual a equipe se comprometeu.

Meu gerente deve participar da retrospectiva ou conduzir a reunião diária?

Geralmente, não. O Guia do Scrum define a retrospectiva como um momento em que a equipe se autoavalia e o daily stand-up como um espaço de coordenação entre os próprios desenvolvedores. A presença de uma figura de autoridade na sala não precisa dizer uma palavra para inibir a honestidade — a pessoa responsável pela aprovação de promoções já é, por si só, uma presença intimidante. Compartilhe as ações a serem realizadas com os superiores, não os lugares na sala.

Leituras relacionadas

• O vazio do seguimento — onde o feedback acumulado e a impotência se encontram.
• Performance: a cerimônia que você encena para o público — o teatro que o Poder torna coercitivo.
• Velocidade: para que serve e como calculá-la — use esse valor para previsões, nunca para notas.
• Pontos de história x horas — por que essa conversão contribui para a manipulação de estimativas.
• Planejamento do sprint (a cerimônia) — em que a estimativa deve ser vista como uma previsão de responsabilidade da equipe, e não como um compromisso.
• Como criar um espaço psicologicamente seguro — franqueza que não dependa de quem está na sala.
• Glossário do teatro ágil — o que são “lavagem de estimativas”, “acumulação de feedback” e “ratchet de velocidade”.