Scrum nasceu para resolver um problema específico: como entregar software num mundo onde o requisito muda mais rápido do que o plano. A resposta foi um ritmo fixo — sprint, planning, daily, review, retro — que dava previsibilidade a um processo que antes era caótico.
O problema é que a velocidade que justificava esse ritmo mudou de ordem de grandeza. Uma feature que levava dois dias de código hoje sai em horas com um agente bem orientado. A cerimônia continua pautada num relógio de 2010: sprint de duas semanas, daily de 15 minutos, retro no fim do ciclo. Quando a unidade de trabalho encolhe e o container que a organiza não encolhe junto, o container vira o gargalo.
Isso não é "Scrum morreu". É uma tese mais estreita e mais defensável: o cadence do Scrum foi desenhado para uma velocidade de execução que não existe mais em times que usam IA de ponta a ponta — e nenhuma adaptação superficial de cerimônia resolve isso, porque o problema é estrutural, não de facilitação.
Por que isso é diferente de "mais uma crítica ao Scrum"
Críticas a cerimônia engessada existem desde sempre — "daily virou status theatre", "retro não muda nada". Essas críticas são sobre execução ruim de um modelo correto. O que está em jogo agora é outra coisa: mesmo um Scrum executado à risca, por um time maduro, assume uma premissa que deixou de ser verdadeira — a de que planejar antecipadamente por um bloco de tempo fixo é a unidade certa de risco a gerenciar.
Num mundo BANI — frágil, ansioso, não-linear, incompreensível — o risco não é mais "o requisito vai mudar durante o sprint". É "a capacidade de execução muda dentro do próprio dia", porque o que era gargalo de mão de obra ontem é resolvido por um agente hoje de manhã. Gerenciar isso com um ciclo de duas semanas é usar uma régua rígida para medir algo que se deforma em tempo real.
Nada se cria, tudo se transforma
Lavoisier disse isso sobre matéria, não sobre metodologia de trabalho — mas a lógica se aplica igual. Quando um time sente que o Scrum de livro não serve mais e começa a ajustar na prática, o resultado quase nunca é invenção do zero. É recombinação de peças que já existem, testadas em outro lugar, com outro nome.
Isso não é motivo para desapontamento. É o oposto: significa que qualquer ajuste que um time faça por necessidade tem chance real de convergir com o que gente séria já validou em outro contexto. Convergência independente é sinal forte — quando times diferentes, sem se falar, chegam na mesma solução, geralmente é porque o problema real aponta pra lá.
Três peças que já têm nome, e valem mais citadas do que reinventadas:
Cadência orientada a evento. Em vez de cerimônia presa ao calendário — planning toda segunda, review a cada duas semanas —, o gatilho é a complexidade real do que chegou. Trabalho simples não pede ritual; trabalho grande, sim. É o mesmo princípio por trás do Kanban, que organiza cerimônia em torno de fluxo, não de caixa de tempo fixa.
Dual-track agile, ou "product trio". A ideia, defendida por gente como Teresa Torres e Marty Cagan, é que PM, design e engenharia decidam juntos a solução na fase de descoberta, antes de qualquer coisa virar backlog fechado. Decisão tomada só por um papel e depois repassada para execução perde justamente o conhecimento técnico que evita retrabalho.
Flow review de Kanban. Um encontro recorrente para olhar o fluxo em andamento e ajustar rota — diferente da sprint review clássica, que presta contas de compromisso fechado ("entregamos o que prometemos"). O deslocamento de critério para "estamos indo na direção certa, resolve a dor real" é mais raro do que parece, e é onde a maioria dos times ainda erra.
A daily silenciosa e o que ela na verdade é
Uma tentação óbvia, com IA acessível, é automatizar a própria daily: um agente lendo Git e board de tarefas via MCP, gerando burndown e resumo automático do que mudou. Isso já tem nome também, e o nome vem da própria arquitetura de agente — sensor, na distinção entre guias (que orientam antes de agir) e sensores (que observam o resultado depois).
Um bot calculando burndown a partir de dado estruturado é sensor computacional — checagem determinística. Se o mesmo bot resume qualitativamente "o que mudou" ou sinaliza risco por inferência, vira sensor inferencial também.
O ponto que não pode ficar de fora: isso resolve a parte de relatar. Não resolve, sozinho, a parte da daily que é social — alguém dizendo "estou travado nisso" antes que vire bloqueio de dois dias. Git e board só mostram o que já foi registrado; não capturam a dúvida que ninguém ainda escreveu em lugar nenhum. Se a automação virar desculpa para ninguém mais se falar, o time troca cerimônia ruim por isolamento — o que é pior.
O risco escondido em qualquer sistema de incentivo
Se a resposta para "como fazer alguém correr atrás de impedimento sem esperar cerimônia fixa" for algum tipo de competição ou ranking entre pessoas do time, vale conhecer o que já foi tentado — e por que boa parte falhou.
Stack ranking — avaliação forçada, comparando pessoas entre si com corte de fundo — foi abandonado por Microsoft em 2013 e por GE, depois de décadas de uso, porque a pesquisa mostrou efeito consistente: engenheiros bons evitavam times fortes, porque ser comparado com colega excelente virava risco de carreira, e ajudar quem também competia por posição passou a ter custo, não recompensa. Colaboração caiu, inovação caiu.
Curiosamente, o padrão está voltando em 2026, com Amazon e Meta apertando avaliação individual e ranking por camada — mas isso acontece em paralelo a ondas grandes de corte de quadro no setor, o que levanta hipótese razoável, não fato comprovado: parte da reintrodução de ranking rígido pode servir para justificar demissão, não para melhorar performance de time pequeno tentando reter talento.
Gamificação voluntária — leaderboard, disputa, bonificação — tem histórico mais misto na pesquisa. O que determina se funciona não é o mecanismo de ranking em si, é o que exatamente está sendo recompensado. E aqui existe um framework mais útil do que qualquer caso de big tech: a literatura de segurança do trabalho, que enfrentou esse problema décadas atrás.
A distinção central é entre indicador de comportamento e indicador de resultado. Premiar resultado puro ("zero incidente") cria incentivo perverso — a pessoa produz a métrica desejada por outros meios, não o comportamento real. A alternativa validada é premiar o comportamento diretamente: reportar cedo, não o resultado de nunca ter tido problema.
Aplicado a qualquer sistema de incentivo de time: sinalizar impedimento a tempo precisa ser um eixo de pontuação próprio, separado da velocidade de entrega — não um desconto em quem atrasou. Se vira desconto, o incentivo empurra para esconder trava. Se vira ponto positivo isolado, o incentivo aponta pro lado certo. E quem ajuda a resolver o impedimento do outro também precisa pontuar — sem isso, ajudar colega vira custo puro, o mesmo erro que destruiu colaboração em todo caso de stack ranking documentado.
O que fazer com "pronto", quando quem escreve o código às vezes é uma IA
Definition of Ready e Definition of Done são dois acordos de time — o que precisa estar claro antes de começar, o que prova que terminou de verdade — que a maioria dos times já usa, com formato variando de time para time. O mercado está dividido sobre se IA muda isso.
Um lado argumenta que nada muda: os critérios continuam os mesmos, só a forma de evidenciar cada um é que muda. Outro lado, mais recente, defende que "pronto" deixa de ser checklist estático e passa a incluir capacidade de detectar quando algo dá errado depois do deploy — o foco desloca de "passou no teste" para "continua funcionando com o tempo".
O que não é discutível: responsabilidade final continua inteiramente humana, independente de quem gerou o código. Toda sugestão de IA deveria ser tratada como rascunho a verificar, com o mesmo rigor que se daria a código escrito por terceiro.
Três itens que os times mais avançados nessa transição estão adicionando ao próprio DoD, não substituindo o que já existia:
* Código gerado por IA foi revisado com o mesmo rigor de código externo
* Está definido o que o sistema faz quando a IA erra ou fica em dúvida — esse caminho não pode ficar sem resposta
* Se envolve IA rodando em produção, existe verificação contínua depois do deploy, não só checagem pontual antes de subir
Vale reforçar o que sempre valeu para DoR e DoD, e que a pressa da IA não muda: acordo imposto de cima, sem o time ter ajudado a criar, tende a ser ignorado. A regra de ouro continua sendo a mesma de sempre — só a lista de itens ficou mais longa.
Fechando, sem fechar
Esse ensaio termina em pergunta, de propósito. Um texto que chegasse até aqui com framework pronto, batizado, testado — estaria mentindo sobre quanto essa mudança já foi validada de verdade.
O que fica: o Scrum de calendário fixo já não é resposta natural de time maduro exposto a variação real de complexidade, e o vocabulário para nomear a alternativa já existe, espalhado entre Kanban, dual-track agile, harness engineering e a literatura antiga de incentivo comportamental. O trabalho que falta não é inventar. É montar essas peças com intenção, sabendo qual risco cada uma resolve — e qual risco continua sem solução pronta.