Nenhum framework compensa falta de decisão
Depois de 25 anos em tecnologia, cheguei a uma conclusão incômoda: o problema nunca foi o método.
Já perdi as contas de quantas empresas vi adotarem Scrum, SAFe, OKRs — e continuarem exatamente do mesmo jeito: lentas, caras, imprevisíveis.
O diagnóstico que se repete é sempre o mesmo: o framework não colou, o time não abraçou, a cultura não estava pronta. E a solução proposta é invariavelmente a mesma: trocar o framework. Tentar outro. Contratar um novo consultor. Rodar mais um ciclo de treinamento.
O problema é que esse diagnóstico está errado. E enquanto ele persistir, o resultado vai ser o mesmo.
O teatro da agilidade
Existe um padrão que se repete com uma regularidade perturbadora em organizações de todos os portes e setores.
Times organizados por produto, mas cobrados por função. Liderança pedindo mais velocidade, mas mantendo três níveis de aprovação para qualquer decisão relevante. Métricas de esforço em vez de fluxo ou resultado. Tecnologia ainda tratada como centro de custo — não como capacidade que gera negócio.
Nesse cenário, você pode rodar quantos rituais quiser. Daily, planning, retrospectiva, PI planning. O resultado não muda. Porque o problema não está na cadência das cerimônias. Está nas decisões estruturais que ninguém está disposto a tomar.
Agilidade virou teatro. E o palco está sempre cheio.
O que agilidade de verdade exige
Agilidade em escala — a que gera velocidade real, previsibilidade real, resultado real — não começa com a escolha do framework. Começa com quatro movimentos estruturais que a maioria das organizações evita porque são desconfortáveis.
Redesenhar a organização em torno de value streams. Não de funções, não de departamentos, não de especialidades. De fluxos de valor — do início ao fim, com times que têm autonomia e responsabilidade sobre o resultado completo. Enquanto a estrutura for funcional, a coordenação vai consumir mais energia do que a entrega.
Reduzir WIP antes de cobrar velocidade. Work in progress excessivo é o principal destruidor de fluxo em qualquer sistema de entrega. Times que trabalham em dez frentes simultaneamente não são mais produtivos — são mais ocupados. Cobrar velocidade sem controlar WIP é como pedir para um sistema sobrecarregado processar mais requisições. Ele não acelera. Ele trava.
Trocar a sensação de controle por previsibilidade de fato. Aprovações em cascata, gates de revisão, comitês de priorização — tudo isso gera uma sensação de controle que raramente corresponde a controle real. Previsibilidade de entrega vem de fluxo estável, não de supervisão. São coisas diferentes, e confundi-las é um erro caro.
Aceitar que parte do problema está na liderança — não no time. Esse é o movimento mais difícil. E o mais necessário.
A decisão que nenhum framework toma por você
Foi como CTO que aprendi isso na prática, conduzindo transformações em ambientes complexos, de alta escala, com legado técnico pesado e pressão constante por resultado.
Agilidade começa a funcionar quando a pergunta para de ser qual framework a gente adota e passa a ser quais decisões estruturais a gente está evitando tomar.
Essa mudança de pergunta é mais difícil do que parece. Porque as decisões que travam a agilidade raramente estão no nível do time. Estão no nível da liderança executiva — na forma como a organização está estruturada, como a prioridade é definida, como o sucesso é medido, como o poder de decisão está distribuído.
Nenhum Scrum Master resolve isso. Nenhum release train engineer resolve isso. Nenhum coach ágil resolve isso.
São decisões executivas. E precisam ser tomadas por executivos.
A pergunta que deveria vir antes
Antes de qualquer discussão sobre framework, antes de qualquer investimento em transformação ágil, há uma pergunta que precisa ser respondida com honestidade:
Nossa liderança está disposta a mudar a forma como a organização está estruturada — ou está esperando que o framework faça isso por ela?
Quando a resposta é sim, a agilidade tem chão para funcionar. O framework vira ferramenta, não solução.
Quando a resposta é não, o debate sobre Scrum versus SAFe é apenas uma forma de adiar uma conversa mais difícil — e mais necessária.
O resto é teatro.








