Seu time não está lento. Ele está esperando.

Toda área de engenharia que eu conheço tem uma meta de cycle time. E toda área de engenharia que eu conheço convive com itens que passam longe dela.

Em times que liderei, a gente tinha atividades que ficavam 30, 40, 60 dias travadas. Não eram itens gigantes, não eram projetos. Eram atividades comuns, do tamanho de qualquer outra, que simplesmente não terminavam.

Quando isso aparece num relatório, a primeira explicação que alguém oferece é sempre a mesma: o time está lento. É a explicação mais barata e a mais confortável, porque ela aponta pra um lugar só e não obriga ninguém a mudar de comportamento.

A gente decidiu não aceitar essa explicação sem olhar.

A autópsia

Começamos a analisar uma série de itens que estouravam o cycle time. Cada atividade travada, cada retrabalho, virava uma pequena investigação. Ninguém estava atrás de quem errou. A gente queria saber uma coisa só, e bem mais chata de responder: o que esse item estava esperando?

Chamo isso de autópsia porque é exatamente o que é. Você abre depois que já morreu, sabendo que não vai salvar aquele item. Você abre pra descobrir do que ele morreu, e pra ver se o próximo morre da mesma coisa.

É um trabalho chato, e os primeiros resultados são pequenos. Ninguém resolve a esteira inteira olhando poucos itens, uma vez só. Mas a constância desse tipo de análise vai compondo, e é aí que ela surte efeito.

O que apareceu

Quatro motivos se repetiam com uma frequência que incomodava:

Ainda faltava infraestrutura ou algo no banco de dados. Não dava pra testar. O item ficava pronto, parado, esperando um ambiente.

Os acessos necessários não estavam liberados. Não dava pra entregar pro cliente. Item concluído do lado do time, e mesmo assim sem chegar a lugar nenhum.

Retrabalho que, olhando de perto, não era retrabalho. Ao longo do desenvolvimento, alguém percebia a necessidade de critérios de aceite que não existiam no começo. Esses critérios eram incorporados ao escopo original e voltavam pro time com o rótulo de "retrabalho", quando na verdade eram escopo novo, entrando por uma porta que ninguém estava vigiando.

"Ainda faltam algumas definições, mas vai começando que a gente valida durante a sprint." Essa é a ilusão em que a gente quer se agarrar, mesmo sabendo onde vai dar: a definição demora a chegar, o escopo aumenta, e o prazo de entrega não... rs.

Nenhum desses é problema de execução

Olha a lista de novo, porque foi ela que mudou a nossa cabeça.

Três dos quatro motivos são espera. Um é definição incompleta. Nenhum tem a ver com a velocidade com que alguém escreve código.

O tempo daqueles 60 dias não foi gasto fazendo. Foi gasto esperando e refazendo.

Isso reformula completamente a pergunta. "Como fazer o time entregar mais rápido" é uma pergunta que leva direto pras respostas erradas: contratar mais gente, apertar prazo, cobrar mais. Nenhuma delas toca em espera nem em definição incompleta. Você acelera o trecho que já era rápido e o item continua parado 40 dias esperando um ambiente.

A pergunta certa é mais desconfortável: por que a gente deixou esse item entrar assim?

O remédio é contra-intuitivo

Se o problema está na entrada, não adianta acelerar o meio.

A conclusão a que chegamos foi que as idas e vindas de uma atividade custam muito mais caro do que segurar ela na porta. Garantir que um item só siga adiante quando estiver de fato pronto pra seguir deixa o processo mais fluido e, no total, mais rápido, mesmo parecendo mais lento no começo.

As autópsias viraram um playbook. Um checklist rápido, que os agilistas rodam antes de qualquer coisa entrar em sprint.

As três perguntas

São só três, e são simples:

1. Alguém do time vê alguma ambiguidade ou indefinição na especificação?
2. Sentem falta de algum critério de aceite que não está aí?
3. Depende de alguém, ou de alguma outra área, pra isso chegar até produção?

Antes de você achar que isso é pouco, repara de onde cada uma delas veio:

Nenhuma dessas perguntas veio de um livro de boas práticas. Cada uma existe porque um problema específico aconteceu vezes o suficiente pra a gente cansar dele.

É por isso que eu não acho que você deva copiar essas três.

A parte difícil não é o checklist

No começo teve muito choro e ranger de dentes. E não era birra: antes do checklist, as coisas realmente "começavam mais rápido" e "com menos burocracia". O que a gente ainda não tinha medido é que começar rápido e terminar rápido não são a mesma coisa.

O que fez a coisa funcionar não foi o checklist em si. Foi ter dado ao agilista autoridade real pra barrar o item — inclusive quando quem está empurrando é o PO ou o Tech Lead.

Esse ponto não é negociável, e é onde a maioria das tentativas morre. Como as duas origens mais comuns de item mal definido são exatamente a especificação rasa e a dependência não mapeada (ou seja, PO e Tech Lead), um portão que não alcança esses dois não filtra nada.

Nesse ponto, o papel do agilista não é julgar o mérito: é garantir que a lei seja aplicada.

É um papel ingrato, e vale dizer isso com todas as letras: quem paga o custo de segurar um item é o agilista, que leva a bronca na hora. Quem colhe o benefício é o time, três semanas depois, sem nem perceber. Ninguém sustenta isso por boa vontade. Sustenta por mandato explícito.

E quando o escopo cresce depois que o item já entrou?

Cresce mesmo. Nenhum portão de entrada resolve isso, e seria desonesto sugerir o contrário. Aliás, tentar impedir que o escopo mude iria na contramão do próprio ágil: mudança é bem-vinda, e deve ser mesmo. O que não pode é ela ser invisível.

O acordo que a gente tem é: escopo que entrou na sprint é imutável. Se precisar evoluir, vira um incremento de escopo, registrado à parte. Pode até ser atendido na mesma sprint, se houver folga; se não houver, vai pro ciclo seguinte.

Repara que a gente não proibiu o escopo de mudar. Isso seria burocracia, e não sobreviveria ao primeiro cliente irritado. A gente proibiu o escopo de mudar em silêncio. É uma intervenção muito mais barata, e muito mais difícil de sabotar.

"Por que o dev atrasou?"

Os incrementos registrados são discutidos em retro. Mas o retorno mais forte deles não aparece na retro. Aparece naquele momento em que alguém faz a pergunta infame: por que o dev atrasou?

Com o registro na mesa, o motivo fica evidente e a discussão morre ali mesmo.

Isso é mais importante do que parece. Sem registro, caímos na tentação da solução fácil: trocar pessoas do time porque achamos que não estão com boa performance, inchar mais o time com mais pessoas que não vão trazer resultado em curto prazo, ...

Com registro, tomamos o remédio para curar a doença e não para "abaixar a febre". E dá pra fazer isso sem expor ninguém: o que interessa é entender onde o problema realmente está, e construir junto uma solução de verdade.

O que eu faria no seu lugar

Não copie as minhas três perguntas. Elas resolvem os meus problemas, não necessariamente os seus.

Faz o seguinte, que custa uma tarde:

Pega os cinco últimos itens que estouraram o prazo no seu time. Pra cada um, responde uma pergunta só: o que ele estava esperando? Não "quem atrasou", não "quanto tempo levou". O que ele estava esperando.

Você vai ver padrão nos primeiros três. E as perguntas do seu checklist vão sair sozinhas dali.

Uma última coisa, porque seria desonesto não dizer: esse checklist não é bala de prata, e nem é pra sempre. O nosso mesmo vai mudar. Conforme o time vai assimilando, alguns desses itens param de ser problema e ninguém precisa mais perguntar sobre eles — e outros, que hoje nem existem, vão aparecer no lugar. Ele muda junto com o time, e só continua valendo enquanto refletir os problemas que vocês têm agora. Não é coisa de escrever uma vez e pendurar na parede.

O time provavelmente não está lento. Ele está esperando alguma coisa que ninguém mediu.