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 de velocidade é a forma como 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 apenas um parâmetro de autoavaliação da equipe e passa a ser uma meta de produtividade, transforma-se em 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 burras, 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, reconhece 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 parâmetros adequados é 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 espera, taxa de falhas nas alterações e tempo de restauração), e a velocidade foi deliberadamente deixada de fora, pois os pontos de história 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 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, exigir que a equipe cumpra esse compromisso 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 ter “errado na 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, refaça”) até que a equipe apresente qualquer número que faça a data bater; a partir daí, 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, o mesmo instinto não entra em ação. 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 abordagem padrão é a de Mike Cohn e é anterior à nossa terminologia: 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 suposições 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 é a causa do fracasso, 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 um bônus, 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 guerra são específicas e doem. Um engenheiro descreveu como o feedback de uma retrospectiva ressurgiu em uma 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 na hora da revisão do seu bônus anual. O efeito inibidor nem precisa envolver 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 algo vago 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 — um estudo de dois anos com 180 equipes — revelaram 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 farsa com risco jurídico associado. 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 firmeza) 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 aborda a 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 em sigilo. A velocidade é um dado de entrada para previsões, não uma métrica de desempenho. A pesquisa DORA a exclui deliberadamente porque 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 “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 a formulação das palavras.

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 a reunião diária?

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 prejudicar 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 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 a conversão contribui para a manipulação de estimativas.
• Planejamento do sprint (a cerimônia): onde 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.
• Glossário do teatro ágil: o que são “lavagem de estimativas”, “acúmulo de feedback” e “ratchet de velocidade”.