Rituais sem motivo

A maioria dos times de engenharia com que trabalhei nos últimos vinte anos rodava Scrum sem conseguir dizer para que servia a sprint. A maioria deles está adotando IA do mesmo jeito, e colhendo o mesmo resultado: a cerimônia sem o efeito.

Esta é a primeira edição da Destravado. Cada edição pega uma coisa que impede times de engenharia de entregar e olha para o que de fato remove esse bloqueio. Quis começar pelo bloqueio mais antigo que conheço, porque estou vendo ele acontecer de novo, com um vocabulário novo e uma conta muito mais alta.

O problema não é o Scrum, e não é a IA. O problema é adotar uma prática porque todo mundo adotou, sem nunca aprender por que ela existe. Eu aprendi isso do jeito lento, então deixa eu começar de onde comecei.

2007: o que quer dizer "Agile Web Development"?

Aprendi Ruby on Rails em 2007 pelo livro que todo mundo usava para aprender: Agile Web Development with Rails, de Dave Thomas e David Heinemeier Hansson. Tinha acabado de me formar em Design Gráfico, tinha meus primeiros clientes próprios e precisava entregar aplicações web para eles. O livro cumpriu o prometido. Construí coisas com ele.

Mas o título me incomodava. Eu entendia "Web Development" e entendia "Rails". Não fazia ideia do que "Agile" estava fazendo na frente dos dois. O próprio livro não explicava; a palavra estava no ar, e os autores assumiam que você já sabia.

Perguntei por aí. As respostas eram variações de "quer dizer iterativo" e "quer dizer rápido". Isso não era uma explicação, era um sinônimo. Então fiz o que ainda faço quando uma palavra é usada por todo mundo e definida por ninguém: fui à fonte. A fonte era Agile Software Development with Scrum, de Ken Schwaber e Mike Beedle, publicado em 2001 e, até onde sei, o primeiro livro escrito sobre Scrum.

Esperava um manual de processo. Encontrei uma história sobre caos.

Para que o Schwaber criou o Scrum

Schwaber não partiu de cerimônias. Partiu de fracasso. O livro abre com uma lista de projetos que desabaram sob o peso do próprio planejamento: uma empresa que cancelou um projeto grande depois de dois anos sem entregar nada, metodologias que deixavam a própria empresa dele mais lenta enquanto "os requisitos da minha empresa estavam sempre mudando", times soterrados por uma complexidade que tinham prometido controlar.

Em 1995 ele levou as metodologias da época aos especialistas em controle de processos da DuPont, liderados por Babatunde Ogunnaike. A resposta deles mudou a carreira do Schwaber: desenvolvimento de software é imprevisível demais para um processo definido, do tipo que se planeja uma vez e se executa. Precisa de um processo empírico, que inspeciona com frequência e se adapta, e que, nas palavras dele, "espera o inesperado". O Scrum é essa resposta posta no papel.

Tudo no livro de 2001 decorre disso. A Sprint tinha trinta dias e era uma janela protegida: o time se compromete com um objetivo e um backlog, e ninguém de fora mexe nisso até a Sprint acabar. Essa regra é o ponto central. É assim que se dá espaço para um time trabalhar enquanto gestão, vendas e clientes continuam mudando de ideia, o que eles vão fazer, porque o processo é empírico.

Cada reunião tinha uma única função dentro desse ciclo:

• O planejamento da Sprint existia para produzir um objetivo e um compromisso. O Product Owner traz o topo do backlog; o time decide quanto daquilo consegue transformar em software funcionando e define para que serve a Sprint. O time se compromete; ninguém atribui.
• A Daily existia para sincronizar o time e expor impedimentos, em quinze minutos, para que o Scrum Master fosse removê-los. Nunca foi um relatório de status para um gerente.
• A revisão da Sprint existia para mostrar software funcionando, não slides, e deixar os stakeholders inspecionarem e redesenharem o backlog. É aqui que a gestão recupera o controle: a cada trinta dias, sobre funcionalidade real, em vez de toda tarde, numa thread do Slack.
• O encerramento anormal existia porque, fora isso, a Sprint era intocável. Se o objetivo deixasse de fazer sentido, encerrava-se a Sprint e planejava-se de novo. O livro diz que isso raramente deveria acontecer. O fato de estar escrito mostra o quanto a janela protegida era levada a sério.

Duas coisas que eu lembrava como parte do desenho original ainda não estavam lá. A retrospectiva, o momento em que o time inspeciona como trabalha e não só o que construiu, só apareceu no livro de 2004 do Schwaber, Agile Project Management with Scrum. E o grooming do backlog, a prática de manter o backlog ordenado, quebrado e podado, foi adicionado ao Scrum Guide em 2011 e renomeado "refinamento" em 2013. Os dois foram acrescentados pelo mesmo motivo que o resto: o ciclo empírico precisa ser aplicado ao processo e ao backlog, não só ao produto.

Era isso que a palavra no título do livro de Rails queria dizer. Não rápido. Não iterativo por ser iterativo. Um conjunto de controles desenhado para que um time mantivesse o chão firme enquanto o terreno se movia, e para que as pessoas movendo o terreno tivessem um lugar legítimo e agendado para fazer isso.

Tudo o que vi desde então é ao contrário

Trabalhei em times de staffing de saúde, fintech, e-commerce, rede profissional e pesquisa, no Brasil, nos Estados Unidos e na Europa. Quase todos rodavam "Scrum". Consigo contar nos dedos de uma mão os que usavam as cerimônias para o que elas foram desenhadas. O padrão é consistente o bastante para eu descrever sem citar ninguém.

A sprint não tem objetivo. Ela tem duas semanas e é uma lista. Alguém puxou os N tickets do topo do board até os pontos baterem com a velocidade da sprint passada, e isso virou o plano. Pergunte a qualquer um na sala para que serve a sprint e você recebe uma pausa, depois um número de ticket. Sem objetivo não há nada para proteger, então nada é protegido: entra trabalho na quarta, a prioridade vira na sexta, e a sprint termina com 60 a 80 por cento feito. Toda vez. O time aprende que o compromisso é teatro e para de tratá-lo como compromisso.

O grooming não limpa nada. A sessão que existe para manter o backlog ordenado e mais curto virou reunião de estimativa. Os itens entram, ganham um número e ficam. Nada é removido; o backlog cresce por anos até virar um cemitério que ninguém lê além da primeira página, o que significa que o Product Owner está, na prática, planejando a partir de uma lista diferente da que o time enxerga.

A planning leva trinta minutos. Como os tickets "já foram estimados" no grooming, planejar se reduz a arrastá-los para a coluna da sprint. Ninguém relê as prioridades com contexto fresco. Ninguém pergunta se aquilo que foi estimado três semanas atrás ainda importa. Aí a sprint não fecha, e a retrospectiva conclui que o time "se comprometeu demais".

As retrospectivas são frequentes demais para serem profundas. Com sprints de duas semanas, tem retrospectiva a cada dez dias úteis. Isso cansa, então ela é comprimida: trinta minutos, três colunas, uma rodada de "foi bem / não foi bem", um item de ação sem dono. A única cerimônia cujo trabalho é fazer o time pensar sobre como trabalha vira a que todo mundo quer deixar mais cedo. Já sentei em centenas delas. Lembro de meia dúzia que mudaram alguma coisa.

Cada uma dessas é a forma de uma cerimônia do Scrum com o motivo esvaziado. A reunião está na agenda; a decisão para a qual ela foi criada não está sendo tomada.

"Mas o software mudou"

A objeção justa é que o Scrum foi desenhado para outro mundo. Em 2001 software era entregue em cronograma, muitas vezes num CD. Lançamento era evento. Não havia pipeline de CI/CD, nem feature flag, nem deploy quarenta vezes por dia. Uma janela protegida de trinta dias fazia sentido quando integrar e lançar era, por si só, um mês de trabalho. Hoje pode parecer um luxo que ninguém pode pagar.

Concordo com a premissa. Não concordo com onde as pessoas a levam.

Se uma sprint de trinta dias não cabe no jeito como entregamos software hoje, uma sprint de quatorze dias também não cabe. É o mesmo instrumento, cortado ao meio, sem nenhuma das mecânicas ao redor reexaminada. O que aconteceu de fato foi que os times mantiveram a caixa, encolheram a caixa e depois descartaram cada parte do desenho que não sobreviveu ao encolhimento: o objetivo, o compromisso, o backlog podado, a revisão de verdade, a retrospectiva de verdade. Se entrega contínua realmente torna a janela protegida obsoleta, o movimento honesto é adotar um jeito de trabalhar baseado em fluxo e dizer isso. Manter as cerimônias e abandonar os motivos não é modernização. É inércia com agenda.

E esta é a parte que custa mais do que velocidade. Um time que roda cerimônias vazias por anos aprende, corretamente, que processo é algo feito contra ele. Compromisso não significa nada, então para de se comprometer. Retrospectiva não muda nada, então para de levantar problemas. A prática que foi criada para proteger o time do caos vira mais uma fonte de caos, com seis horas de reunião por sprint de brinde.

Steve McConnell deu nome a isso em 2000, numa coluna na IEEE Software: engenharia de software cargo cult. Times imitam os rituais visíveis de times bem-sucedidos sem entender o que fez aqueles times darem certo, e depois se surpreendem que os aviões não pousam. Vinte e cinco anos depois, os rituais mudaram. O culto, não.

O mesmo filme, agora com IA

Estou vendo o padrão idêntico com IA na engenharia, comprimido de vinte anos para dois. A empresa compra as licenças. A adoção é medida, e é alta. Todo mundo está "usando IA". E os números de entrega não se movem do jeito que o slide do fornecedor prometeu.

Os dados não são sutis. Num estudo randomizado publicado pela METR em julho de 2025, dezesseis desenvolvedores experientes de projetos open source trabalharam em 246 issues reais dos próprios repositórios, com e sem ferramentas de IA. Com IA eles levaram 19% mais tempo. Antes do estudo, previam ficar 24% mais rápidos; depois dele, ainda acreditavam ter sido 20% mais rápidos. A diferença entre a produtividade sentida e a medida foi de uns quarenta pontos. O relatório DORA de 2024 encontrou que o aumento do uso de IA veio acompanhado de uma queda estimada de 1,5% no throughput de entrega e de 7,2% na estabilidade. O relatório de 2025, com adoção em torno de 90%, viu o throughput virar positivo, mas a instabilidade seguir subindo, e o líder da pesquisa resumiu numa frase: "não é se você está usando IA que determina o resultado, é como você está usando". O próprio enquadramento do DORA é que IA é um amplificador. Ela aumenta o que a organização já é.

E como a maioria dos times está usando? Pelo que vejo dentro das bases de código, do mesmo jeito que rodam sprints: o ritual sem o motivo.

• Nenhum entendimento do harness. Engenheiros não sabem o que é um system prompt, o que a ferramenta injeta nele, como skills, plugins e comandos são carregados, como a ferramenta indexa a base de código ou infere contexto. Tratam o agente como um chat com acesso a arquivos, e se surpreendem quando ele se comporta como um.
• Prompts genéricos. "Corrige o bug no checkout." Sem papel, sem restrições, sem exemplos, sem saída esperada. Nenhuma das técnicas que estão documentadas e são baratas de aprender: role prompting, zero-, one- e few-shot, chain of thought, skeleton of thought, loops no estilo ReAct. O prompt é a única entrada que o engenheiro controla por completo, e é a única em que ninguém é treinado.
• Nenhuma engenharia de contexto. Quinze skills carregadas de uma vez, todas disputando atenção. Nenhuma definição de quais arquivos podem ser lidos e quais podem ser escritos. Sem spec, sem PRD, então o agente lê metade da base de código para entender uma mudança em dois arquivos. Aí o contexto enche, o modelo perde o fio, e o time conclui que "ele alucina".
• Nenhum modelo mental de como agentes funcionam. A diferença entre uma execução autônoma, um sub-agente com contexto próprio e um loop simples é invisível para a maioria dos times. Disparam um agente totalmente autônomo para um fix de uma linha e usam autocomplete para uma migração de schema.

A esses quatro eu acrescento os que mais encontro quando sou chamado:

• Nenhum ciclo de verificação. A saída do agente é tratada como pronta. Sem teste antes, sem evals, sem diffs pequenos. A revisão vira o gargalo, e os revisores passam a ler muito mais código do que escrevem. A frase do DORA de 2025 cabe exatamente: "o atrito não desaparece, ele se move", para decidir e verificar.
• Uma base de código que ninguém preparou para um leitor-máquina. Sem diretrizes escritas, sem notas de arquitetura, sem arquivo de convenções. O agente faz o que agentes fazem: replica o que já está lá, incluindo a bagunça, em alta velocidade.
• Ferramenta primeiro, fluxo de trabalho depois. Compra Cursor ou Copilot, mede licenças ativadas, chama de estratégia. O fluxo ao redor da ferramenta, onde os ganhos ou as perdas de fato moram, nunca é redesenhado.
• Nenhuma linha de base, logo nenhuma medição. Ninguém registrou lead time ou taxa de falha de mudança antes do rollout. "Parece mais rápido" é a métrica, e a METR já mostrou quanto essa métrica vale.
• Nenhum orçamento de treinamento. Prompting, engenharia de contexto e de harness são habilidades, do mesmo jeito que TDD e code review foram habilidades. Empresas que jamais fariam deploy sem um revisor sênior esperam que engenheiros aprendam isso por osmose, nos intervalos entre sprints.

Quanto isso custa

Com as sprints, a conta chegava devagar: moral, confiança, um time que parou de acreditar em compromissos. Com IA a conta chega mais rápido e tem uma linha na fatura.

Começa com context rot. Um agente jogado numa base de código grande, sem spec e sem limites, lê até a janela encher, e a partir daí a saída degrada: esquece a restrição da primeira mensagem, contradiz uma decisão que tomou vinte minutos antes, reinventa um helper que já existe três diretórios ao lado. O time enxerga alucinação. O que aconteceu de fato é que ninguém gerenciou o que o modelo estava olhando.

Depois, acumula. Código que ninguém entende por completo, humano ou máquina, é estendido por uma máquina que entende ainda menos. Não há diretriz para ela seguir nem documentação para ela ler, então a qualidade escorrega para baixo enquanto a base de código cresce sem que ninguém tenha decidido que deveria. Mais código significa mais contexto por tarefa, que significa mais rot, que significa mais bugs e regressões escapando por um processo de revisão que já estava saturado.

E aí vem a fatura. O uso de tokens sobe porque cada tarefa relê os mesmos arquivos, porque quinze skills foram carregadas para um trabalho que precisava de uma, porque o agente fica em loop num teste que falha e cuja causa ele não enxerga. Já vi um agente gastar horas e um valor sério de dinheiro numa mudança que um engenheiro preparado, com um contexto preparado, teria terminado em minutos. Não porque o modelo era fraco. Porque ninguém disse a ele para que servia a sprint.

Entenda antes de adotar

A correção é a mesma nos dois casos, e não é uma ferramenta nova nem um framework novo. É a pergunta que fiz em 2007 sobre uma palavra no título de um livro: por que isso existe? Aplicada a cada cerimônia, e a cada componente do fluxo de trabalho com IA, antes de entrar na agenda ou no repositório.

Para a sprint, comece nomeando a decisão que cada reunião existe para tomar, e se a sua não toma essa decisão, mude a reunião em vez de manter o nome. Depois, se você quer um time de engenharia envolvido com o produto em vez de cuspindo código, o que importa ainda mais agora que o código em si ficou barato, é isto que eu faria:

• Pare com a sprint de duas semanas. Já fazemos deploy várias vezes por dia. A sprint não está mais marcando o tempo dos lançamentos, então pare de fingir que está. Use o ciclo para a única coisa que só um ciclo faz: melhorar o time e o produto.
• Alongue o ciclo e coloque um intervalo nele. O meu formato é de mais ou menos quatro semanas, com dois dias inteiros tirados do ciclo para as cerimônias. Um dia para o fim da sprint: demo, feedback dos stakeholders, uma conversa de verdade sobre para onde o produto está indo. Um dia inteiro para planejar a próxima. O intervalo é onde o fim de um ciclo informa o começo do próximo, em vez de vazar para dentro dele.
• Dê à planning e à retrospectiva o tempo que elas precisam. Um plano montado em trinta minutos a partir de tickets pré-estimados é uma lista. Uma retrospectiva espremida na última meia hora de uma sexta-feira é um ritual. Faça as duas com menos frequência e faça direito.
• Use o refinamento para falar de produto. Ainda estamos indo na direção certa? Esse item ainda merece existir? Estimativa pertence à planning. Refinamento é onde o time e o Product Owner discutem prioridades, e onde o backlog fica mais curto.
• Escolha a janela que você consegue proteger. Se a resposta honesta for "nenhuma", diga isso e vá para fluxo. Proteger uma sprint pela metade é pior do que não ter sprint.

Como uma empresa de software moderna ajustou o ágil: Shape Up

A 37signals é o exemplo público mais claro de uma empresa que manteve os motivos do ágil e reescreveu os rituais. Shape Up, de Ryan Singer, publicado em 2019 e gratuito para ler, descreve como eles constroem o Basecamp. O trabalho acontece em ciclos de seis semanas, "longo o bastante para terminar algo significativo e curto o bastante para sentir o prazo desde o começo", seguidos de um cool-down de duas semanas para correções, trabalho avulso e a decisão do que vem a seguir. Antes de qualquer coisa ser assumida, ela é modelada (shaped): alguém sênior define o problema e os contornos de uma solução, com um apetite (quanto tempo aquilo vale) em vez de uma estimativa. Depois uma mesa de apostas escolhe em que o próximo ciclo vai apostar. Uma aposta significa nenhuma interrupção e a expectativa de terminar. O tempo é fixo; o escopo é variável. E não existe backlog: uma proposta que não recebe aposta é descartada, e se ainda importar, alguém vai trazê-la de volta.

Repare no que sobreviveu do Schwaber: a janela protegida, o único ponto legítimo em que a gestão redireciona, o ciclo de inspecionar e adaptar. Depois repare no que eles mudaram, e por quê. Ciclos mais longos, porque a entrega é contínua e o ciclo não é mais sobre lançar. Sem backlog, porque um backlog de mil itens é o cemitério que descrevi acima. Apetite em vez de estimativa, porque as estimativas nunca estavam certas. Cada mudança remete a um motivo que deixou de valer para eles. É isso que ajustar um método significa: você mantém os motivos e redesenha os rituais, não o contrário.

Código na velocidade da IA, times na velocidade humana

Código agora pode ser escrito na velocidade da IA. O time continua humano, e precisa desses ciclos. O código é binário; o produto é orgânico, o mercado muda rápido, e com IA muda ainda mais rápido. O ciclo é onde os humanos alcançam o que acabaram de entregar e decidem o que deve acontecer a seguir.

Para IA, fica assim:

1. Dedique tempo de verdade para treinar o time. Não só engenharia, mas especialmente engenharia. Como o modelo se comporta antes de como a ferramenta funciona: janela de contexto, atenção, não determinismo, quanto custa um token. Um engenheiro que entende por que a saída degrada quando o contexto enche vai gerenciar contexto sem que ninguém mande. Não deixe o medo de ficar para trás empurrar a empresa para uma adoção cega; quem tirar o tempo para fazer isso direito é quem vai ter números para mostrar.
2. Construa o harness de propósito. Escreva as instruções do projeto. Decida quais skills carregam e quando. Saiba o que a sua ferramenta injeta e o que ela indexa. Trate o system prompt como código: versionado, revisado, com dono.
3. Faça engenharia de contexto. Specs e PRDs antes do código, escritos com método, não improvisados; são o contexto mais barato que você jamais vai dar a um agente. Limites explícitos de leitura e escrita por tarefa. Documentação, fluxos e convenções que o agente consiga ler, porque ele vai ler, e vai seguir.
4. Mantenha o humano no loop e revalide tudo. Testes antes, diffs pequenos, evals para os prompts de que você depende. Desenhe para um modelo que às vezes erra, em vez de se surpreender toda vez que ele erra.
5. Meça contra uma linha de base. Lead time, taxa de falha de mudança, tokens por mudança mergeada. Antes e depois. "Parece mais rápido" é uma sensação, não um resultado.
6. Espere que a produtividade chegue com método e experiência, não com a licença. Existe uma mudança real entre como engenheiros trabalharam por vinte anos e como deveriam trabalhar agora. Essa mudança se aprende, e aprender leva tempo. Orçamente isso como orçamentaria qualquer outra mudança na forma como o time constrói software.

Nada disso é exótico. É o conteúdo de alguns bons livros e de alguns meses de prática deliberada, que é mais ou menos o que o Scrum pedia aos times em 2001, e o que a maioria pulou.

Por que "Destravado"

Passei vinte anos do lado da engenharia em produtos de saúde, fintech, e-commerce e redes B2B, e na maior parte desse tempo o que bloqueava esses times não era técnico. Eram práticas adotadas sem os motivos, arquiteturas herdadas sem as restrições, ferramentas compradas sem os fluxos de trabalho. Esta newsletter é sobre esses bloqueios e sobre o que os remove: às vezes uma decisão de arquitetura, às vezes um processo, cada vez mais uma prática com IA. Um por edição, com dados onde há dados e as minhas próprias cicatrizes onde não há.

Duas perguntas para levar para a semana que vem. Na próxima planning: todo mundo na sala consegue dizer, numa frase, para que serve esta sprint? Na próxima tarefa com IA: o engenheiro consegue dizer o que está na janela de contexto do modelo agora, e por quê?

Se qualquer uma das respostas for uma pausa seguida de um número de ticket, você encontrou o seu primeiro bloqueio. Responda e me conte qual foi.

No fim das contas, a sua empresa não precisa rodar Scrum pelo livro, nem Shape Up, nem nada pelo livro. O ágil deveria ser flexível: um conjunto de motivos que você adapta às necessidades e à cultura da sua empresa, não um conjunto de rituais que você copia. Esse é o argumento inteiro deste artigo, e vale igualmente para a forma como você traz IA para dentro do time.

Se o seu time ou a sua empresa se reconheceu nessas dificuldades, esse é o trabalho da Welaborate Labs: ajudar times de engenharia a adotar IA, e as práticas ao redor dela, de um jeito que apareça de fato na entrega. Dê uma olhada em labs.welaborate.com e agende uma conversa com a gente para entender como podemos ajudar.

Fontes

• Ken Schwaber e Mike Beedle, Agile Software Development with Scrum (Prentice Hall, 2001); trecho do capítulo sobre a visita à DuPont e as origens do Scrum na InformIT
• Ken Schwaber, Agile Project Management with Scrum (Microsoft Press, 2004), onde a retrospectiva aparece pela primeira vez
• Dave Thomas e David Heinemeier Hansson, Agile Web Development with Rails (Pragmatic Bookshelf, 2005)
• Linha do tempo das reuniões do Scrum, a retrospectiva de 2004 e a renomeação de grooming para refinamento em 2011/2013: Scrum: A Brief History of a Long-Lived Hype
• Steve McConnell, "Cargo Cult Software Engineering", IEEE Software, março/abril de 2000
• Estudo randomizado da METR com desenvolvedores experientes, julho de 2025, conforme reportado pelo The Register
• Relatório DORA 2024: adoção de IA e a queda de 1,5% no throughput / 7,2% na estabilidade
• DORA 2025 State of AI-assisted Software Development e o resumo em Research-Driven Engineering Leadership