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 é apenas uma previsão se ninguém acima da equipe estiver avaliando-a. Remova essas suposições (adicione 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 ter o desempenho esperado. 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. Ele foi específico: “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 da velocidade” é o mecanismo pelo qual esse dano ocorre. 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 permitida é para cima. As equipes não são tolas, então respondem da única maneira que o incentivo permite. Elas inflacionam os números. Uma história que valia 3 no trimestre passado 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 de seus limites é a DORA. Uma década de pesquisa sobre os fatores que predizem o desempenho na entrega de software resultou em quatro métricas-chave (frequência de implantação, tempo de ciclo, taxa de falhas nas alterações e tempo de restauração), e a velocidade não está entre elas; 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á a montante desse número. A resposta honesta é: “o que você está realmente tentando medir?”. Nosso capítulo sobre velocidade mostra como mantê-la honesta, e o 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. A “lavagem de estimativas” consiste na 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 o número, a culpa é sua. As estimativas são rejeitadas (“isso não pode estar certo, faça de novo”) 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 “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 vence essa proteção, convertendo os pontos diretamente de volta em uma data.

A correção canônica é a de Mike Cohn e é anterior à nossa criação do termo: 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 o modelo cascata disfarçado. Dave West, da Forrester, chamou isso de “water-scrum-fall”, e a “lavagem de estimativas” é o seu cerne. Nosso capítulo sobre story points versus 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. O “acúmulo de feedback” ocorre quando comentários retrospectivos sinceros são guardados e discretamente usados contra você mais tarde: em uma avaliação de desempenho, na definição de um bônus ou em uma conversa discreta sobre “adequação”. A reunião retrospectiva é apresentada como um espaço seguro para se ser franco. O “acúmulo de feedback” é a descoberta 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 má-fé. A pessoa responsável pela aprovação das 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 de forma 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 — que, ao longo de dois anos, estudou 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 imutável. 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 formal acaba produzindo nada além de aparências controladas, você chega ao vazio do acompanhamento: o quarto modo, e aquele em que o acúmulo de feedback causa seus danos mais silenciosos.

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. Ela não é uma das métricas de entrega da DORA e, de qualquer forma, os pontos não são comparáveis entre 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 observação de que eles reclamam demais. Isso é o que chamamos de “armazenamento 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 a formulação.

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, identifique 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 o Standup?

Geralmente, não. O Guia do Scrum define a retrospectiva como um momento em que a equipe faz uma autoavaliação 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.

Leitura relacionada

• O vazio do acompanhamento: onde o feedback reprimido 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 a conversão contribui para a “maquiagem” das estimativas.
• Planejamento do sprint (a cerimônia): em que a estimativa deve permanecer 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á presente na sala.
• Glossário do Teatro Ágil: “lavagem de estimativas”, “acumulação de feedback” e “ratchet de velocidade” – definições.