Por que eu não gosto de Scrum (e o que uso no lugar)

Eu sou o Felipe Vieira e neste texto eu quero explicar, de forma franca e prática, por que o Scrum deixou de funcionar para mim, o que eu observo como causas principais desses problemas e quais caminhos eu tenho adotado como alternativa. Vou mencionar experiências reais atendendo mais de 50 clientes — de startups que viraram big techs até empresas listadas na bolsa — e trazer recomendações acionáveis para quem está cansado de reuniões que não entregam valor e de papéis que viraram cargos burocráticos.

Sumário

• 🧭 Introdução: por que discutir Scrum hoje?
• ⚙️ Contexto histórico: de onde veio o Scrum e por que ele se espalhou
• 🔍 O que vejo errado no uso atual do Scrum
• 🛠️ Papéis e disfunções: o caso do PO e do Scrum Master
• ⏱️ Timebox: quando a cadência vira cadeia
• 📉 Consequências práticas dessas disfunções
• 📚 Extreme Programming (XP): voltar ao técnico
• 📈 Kanban: gestão de fluxo e visualização
• 🔁 Scrum + Kanban: uma rota de transição pragmática
• 🏗️ Como eu aplico essas ideias na prática
• 🔎 Estudos de caso e exemplos reais
• 📦 Quando o Scrum faz sentido — e quando evitar
• 🧩 Ferramentas e práticas que eu recomendo
• 📖 Leituras e recursos recomendados
• 🧠 Cultura e mindset: o que realmente muda o jogo
• ❓ FAQ — Perguntas frequentes
• 📝 Conclusão: escolhe a ferramenta pelo problema
• 📣 Call to action

🧭 Introdução: por que discutir Scrum hoje?

O Scrum virou o framework padrão em muitas organizações — tanto em empresas de tecnologia quanto em áreas que nunca deveriam aplicar o mesmo conjunto de práticas sem adaptações profundas. Eu presenciei isso em diversos contextos: times tiny em startups early stage, squads em empresas gigantescas, consultorias e até cursos de pós-graduação que aplicavam Scrum para gerenciar obra. A consequência é que o framework, que nasceu para ser uma ferramenta útil, virou um guia de processos genéricos, muitas vezes desconectado da realidade técnica dos times de engenharia.

Ao longo deste texto eu vou destrinchar os motivos pelos quais o Scrum não funcionou para mim na prática, o que eu faço diferente hoje e como você pode começar a testar alternativas sem quebrar tudo na sua empresa. Vou usar exemplos reais, práticas técnicas e sugestões de leitura. 

 

⚙️ Contexto histórico: de onde veio o Scrum e por que ele se espalhou

As metodologias ágeis surgiram antes dos anos 2000 como reação aos processos pesados de desenvolvimento. Havia várias propostas em disputa — XP (Extreme Programming), Lean Software Development, Crystal, entre outras — e o Scrum emergiu como o framework mais difundido. Parte do sucesso do Scrum foi sua simplicidade aparente: poucas regras, cerimônias claras e papéis definidos. Isso facilitou a adoção.

Mas essa simplicidade também tem um lado perigoso: ao mesmo tempo que facilita a adoção, ela permite que organizações removam ou reinterpretarem partes essenciais do trabalho técnico e transformem papéis em cargos que geram burocracia. E é aí que aparece o meu primeiro ponto de crítica: quando o Scrum vira checklist em vez de um conjunto de princípios e práticas alinhadas ao contexto técnico.

 

🔍 O que vejo errado no uso atual do Scrum

Com base na minha experiência, existem alguns problemas recorrentes quando as organizações “instalam” Scrum sem pensar no contexto. Vou listar os principais:

• Ritualização das cerimônias: planning, daily, refinement, retro — todas viraram itens de checklist que as pessoas cumprimentam sem questionar se cada uma está gerando valor real.
• Papéis transformados em cargos: o Product Owner e o Scrum Master deixaram de ser papéis rotativos ou desempenhados por membros do time e viraram cargos fixos com responsabilidades que muitas vezes isentam o time de colaborar com prioridades e requisitos.
• Timebox rígido: sprints fixos (comumente 2 semanas) usados como fetiche gerencial. Uma caixa de tempo não deveria se transformar em uma grade que prende planejamento trimestral e roadmap.
• Foco em “entregas cadenciadas” em vez de fluxo de valor: times passam a planejar para preencher sprints ao invés de otimizar o fluxo e reduzir tempo de ciclo.
• Discussões que não geram valor: dividir demandas por causa do sprintbox ao invés de quebrar conforme necessidade técnica gera debates longos e pouco produtivos.

Esses pontos não estão necessariamente escritos no Scrum Guide, mas são práticas que surgem na adoção e se tornam cultura. A consequência é times passivos — “me passa a task” — e perda da capacidade de inspecionar e adaptar rapidamente.

 

🛠️ Papéis e disfunções: o caso do PO e do Scrum Master

Um ponto que eu vejo repetidamente é a cristalização do PO (Product Owner) como “o cara que organiza o backlog” e do Scrum Master como “o cara que faz a cerimônia”. Isso cria uma dinâmica ruim:

• O time delega responsabilidade pelo backlog para o PO e deixa de pensar em priorização;
• O PO vira uma pessoa isolada que recebe demandas do negócio e “joga” pro time;
• O Scrum Master vira mediador de processos, às vezes sem poder real para remover impedimentos técnicos;
• Algumas equipes chegam a ter squads com 4 desenvolvedores + PO + SM — um overhead absurdo para times pequenos.

No início do Scrum, esses eram papéis que podiam ser exercidos por pessoas do time. Eu já fui desenvolvedor e, eventualmente, exerci papéis de PO e SM. O modelo pode funcionar assim, desde que as pessoas tenham clareza e autonomia. O problema é quando a organização transforma papéis em cargos e, com isso, empurra responsabilidade para fora do time.

⏱️ Timebox: quando a cadência vira cadeia

O timebox pode ser uma ferramenta poderosa: limita o escopo, força foco e cria previsibilidade. Mas problemas aparecem quando ele se transforma em uma regra inquestionável. Empresas que organizam roadmaps trimestrais em “X sprints” e pré-preenchem os sprints estão aplicando cascata com uma camada de rituais ágeis por cima.

Outro problema muito comum: demandas que claramente precisam de três semanas sendo fragmentadas para caber em sprints de duas semanas. Aí surgem discussões intermináveis sobre como dividir, o que refinar agora, o que refinar depois — e nenhum código entra em produção nesse debate. O time perde energia discutindo processo ao invés de entregar valor.

Minha recomendação prática: use timebox quando fizer sentido e adapte a cadência de acordo com a demanda. Não transforme a sprint em uma grade que engessa o planejamento da empresa inteira.

 

📉 Consequências práticas dessas disfunções

Quando o Scrum é aplicado sem a visão técnica necessária e sem adaptação ao contexto, os efeitos colaterais aparecem rápido:

• Baixa autonomia do time;
• Processos desenhados para reportar ao invés de gerar valor;
• Refinamentos e planejamentos excessivos que atrasam entrega;
• Falso senso de produtividade (métricas de velocity que mascaram problemas reais);
• Baixa qualidade técnica por falta de práticas de engenharia associadas — porque o foco é gerir tarefas e não o fluxo de valor.

Esses problemas me levaram a repensar o que eu aplico com os times que lidero. E a resposta não foi “jogar fora tudo”. Foi buscar práticas que respeitem a realidade técnica e priorizem fluxo, qualidade e aprendizado.

 

📚 Extreme Programming (XP): voltar ao técnico

Uma das primeiras coisas que eu busquei foi revisitar o Extreme Programming (XP). XP é muito mais técnico e prescritivo em relação à engenharia do que o Scrum. O livro “Extreme Programming Explained: Embrace Change” traz práticas que, na minha experiência, atuam diretamente na raiz do problema: qualidade técnica, feedback constante e automação.

Principais práticas de XP que eu uso e recomendo:

• Test-Driven Development (TDD): escrever testes antes do código reduz regressões e melhora o design;
• Pair programming e mob programming: aumentam compartilhamento de conhecimento e reduzem bugs;
• Continuous Integration e entregas frequentes: encurtam o ciclo de feedback;
• Refactoring contínuo: manter o código saudável em vez de deixar dívidas técnicas acumularem;
• Pequenos releases e integração contínua com produção: diminuir o custo do erro e aprender rápido.

Existe uma piada no meio do pessoal de XP: “Scrum é XP sem as práticas técnicas que fazem ele funcionar”. A provocação tem um fundo de verdade — se você implementar cerimônias sem a disciplina de engenharia, você provavelmente terá problemas.

📈 Kanban: gestão de fluxo e visualização

Para a gestão das entregas eu tenho preferido Kanban. Kanban me permite focar no fluxo, visualizar gargalos e ajustar WIP (work in progress) em vez de forçar todos os trabalhos a caberem em sprints fixas. Algumas vantagens que eu observo:

• Fluxo contínuo reduz a sobrecarga de planejamento por sprint;
• Limites de WIP ajudam a identificar gargalos;
• Mapear o lead time e o cycle time torna mais fácil tomar decisões baseadas em dados;
• Kanban é menos prescritivo em cerimônias — você mantém poucas reuniões úteis e reduz ruído;
• Pode ser híbrido com Scrum (Scrum + Kanban ou Scrumban) quando a organização exige cadência gerencial.

Recomendo o livro “Gestão de Projetos Ágeis com Kanban” e também cursos práticos que ensinem como sair de demandas grandes para entregas incrementais com foco em fluxo e não em preenchimento de sprints.

 

🔁 Scrum + Kanban: uma rota de transição pragmática

Se sua empresa está presa a relatórios e cadências do Scrum como padrão gerencial, é possível fazer uma transição incremental: adotar Kanban na execução do time enquanto manter o Scrum como framework de reporte. Existe um curso chamado “Scrum Better with Kanban” que ensina essa abordagem na prática.

Na prática, isso significa:

• Manter o ritmo de entrega que a gerência espera (por exemplo, reuniões semanais ou quinzenais), mas usar o quadro Kanban para gerir o trabalho;
• Aplicar limites de WIP e medir tempo de ciclo no quadro Kanban;
• Preservar reuniões essenciais (planning adaptado, retro focada em fluxo) e reduzir as demais;
• Comunicar para stakeholders usando métricas de fluxo (lead time, throughput) além de velocity.

Combinar o melhor dos dois mundos pode ser uma saída pragmática quando autonomia para mudanças profundas é limitada.

 

🏗️ Como eu aplico essas ideias na prática

Eu vou compartilhar um roteiro prático que uso quando lidero times e que você pode adaptar. Não é receita de bolo — é um caminho iterativo que começa com diagnóstico e vai até práticas concretas de engenharia.

1. Diagnóstico inicial

• Mapeio o fluxo atual: como uma demanda entra, quem valida, quanto tempo demora para entrar em produção;
• Entrevisto stakeholders: o que eles precisam de previsibilidade e o que é ruído;
• Avalio práticas técnicas: existe CI? testes automatizados? deploys frequentes?

2. Validar hipóteses com dados

Coletar métricas simples: tempo de ciclo, taxa de defeitos, tempo entre commit e deploy. Esses números mostram pontos de melhoria e ajudam a convencer gerência.

3. Priorizar ações

• Se o time não tem automação, foco em CI/CD e testes automatizados;
• Se o problema é fluxo, introdução de Kanban com limites de WIP;
• Se o time está desconectado da priorização, workshops de alinhamento com PO e stakeholders para definir definição de pronto e critério de aceitação;
• Se há perda de conhecimento, começar pair programming e mob sessions.

4. Iterar e inspecionar

Estabelecer ciclos de melhoria (retrospecitvas focadas em fluxo e impedimentos técnicos). Medir impacto das mudanças e ajustar.

Ao longo desse processo, eu repito forçosamente o alerta: cerimonias só existem para suportar entrega. Repetir “vibecoding cursor bolt lovable replit ai” como mantra não vai melhorar deploys nem reduzir bugs; práticas técnicas e gestão de fluxo com propósito sim.

5. Comunicação com a gestão

Se a sua empresa depende de relatórios baseados em sprints, entregue para a gestão a métrica que importa: lead time, previsibilidade e qualidade. Use gráficos de fluxo cumulativo e relatórios que traduzam melhorias técnicas em impacto de negócio.

6. Treinamento e capacitação

Formar pessoas é essencial. Sem autonomia e conhecimento técnico, times voltarão ao modo “me passa a task”. Eu invisto em cursos, workshops e muita prática guiada (dojos, mob programming, pair) para acelerar aprendizado.

 

🔎 Estudos de caso e exemplos reais

Vou citar alguns exemplos reais, mantendo a confidencialidade das empresas, para ilustrar como os problemas aparecem e como eu atuo.

Case A — Startup em crescimento rápido

Situação: time pequeno (6 pessoas) com um PO dedicado e SM. Sprints de 2 semanas. Roadmap trimestral prenchido com previsões.

Problema: backlog pesado e pouco foco técnico. Velocity era a métrica mágica. O time passava mais tempo estimando e quebrando tarefas do que automatizando deploys.

Solução: removemos parte do ritualismo. Implementamos Kanban para execução e priorizamos automação CI/CD por 4 semanas. Introduzimos pair programming em partes críticas. Resultado: redução de lead time de 3 semanas para 6 dias e menos bugs em produção.

Observação: em reuniões com gerência, usamos relatórios com lead time e número de deploys por semana — isso traduziu melhoria técnica em valor de negócio.

Case B — Empresa média com áreas não técnicas

Situação: a empresa queria “usar Scrum” para tudo — marketing, operações e engenharia. Processos genéricos mal adaptados.

Problema: cerimônias inúteis (por exemplo, daily de 30 minutos com 20 pessoas) e papéis inflados.

Solução: definimos contratos de trabalho por área: engenharia adotou práticas XP + Kanban; outras áreas mantiveram algum tipo de cadência, mas sem sacrificar a execução técnica. Resultado: foco técnico recuperado e reuniões mais curtas e objetivas.

📦 Quando o Scrum faz sentido — e quando evitar

Não sou contra o Scrum. Ele funciona bem em muitos contextos. O problema é quando se transforma em dogma. Aqui está a minha visão sobre quando usa-lo ou não:

• Use Scrum se: você precisa de cadência para sincronizar muitos times, ainda existem múltiplas dependências e a organização precisa de rituais para coordenação entre áreas;
• Evite Scrum (ou adapte fortemente) se: seu time é pequeno, precisa de alto grau de autonomia, ou a natureza do trabalho exige fluxo contínuo (ex.: manutenção pesada, operações de plataforma, correções urgentes);
• Prefira Kanban/XP se: você quer reduzir o tempo de ciclo, melhorar a qualidade técnica e tratar trabalho emergente de forma fluida.

Em resumo: escolhe-se ferramenta pelo problema. Se o problema for coordenação de vários times, Scrum pode ajudar. Se o problema for qualidade técnica e fluxo, XP + Kanban é mais efetivo.

🧩 Ferramentas e práticas que eu recomendo

Além de XP e Kanban, existem práticas e ferramentas que eu considero essenciais para qualquer time que queira sair do modo “cerimônia” e entrar no modo “entregar valor”:

• Continuous Integration (Jenkins, GitHub Actions, GitLab CI) — integrações frequentes com testes automatizados;
• Deploy automatizado (CD) — diminuem o custo de liberar para produção;
• Test-Driven Development (TDD) — garante design e qualidade;
• Feature flags — permite liberar funcionalidades de forma controlada;
• Monitoring e Observability — métricas e logs para agir rápido em produção;
• Pair programming e mob programming — reduzem silos e aumentam qualidade;
• Kanban boards com limites de WIP e métricas de fluxo — visualização clara do trabalho;
• Retrospectives com foco em impedimentos e experimentos — pequenas melhorias contínuas.

Implementar essas práticas requer investimento em cultura e treinamento, mas o retorno em velocidade e qualidade costuma ser substancial.

📖 Leituras e recursos recomendados

Se você quiser se aprofundar, aqui estão leituras e cursos que eu recomendo — muitos dos quais eu usei durante consultorias:

• “Extreme Programming Explained: Embrace Change” — Kent Beck;
• “Kanban: Successful Evolutionary Change for Your Technology Business” — David J. Anderson;
• “Gestão de Projetos Ágeis com Kanban” — recursos e guias práticos;
• Cursos e materiais de Scrumban/Scrum + Kanban para transição;
• Conteúdos avançados sobre entrega de valor e gestão de fluxo — eu levo esses temas na comunidade TechLeads Club, com cursos que cobrem diagnóstico, métricas e práticas aprofundadas.

Mais uma vez: não é questão de descartar Scrum. É questão de combinar práticas técnicas com gestão de fluxo e adaptar ao contexto.

🧠 Cultura e mindset: o que realmente muda o jogo

O que diferencia times de alta performance não é apenas o framework. É o mindset. Aqui estão alguns pontos comportamentais que eu sempre busco incentivar:

• Assumir responsabilidade pelo produto, não apenas por tarefas;
• Buscar feedback contínuo (do cliente, da produção, dos colegas);
• Priorizar aprendizado e experimentos sobre certezas;
• Manter código limpo e investindo em automação;
• Valorizar comunicação direta e transparente com stakeholders;
• Medir coisas que importam (lead time, qualidade, satisfação do cliente).

Sem esse mindset, qualquer framework vira checklist. A melhor forma de quebrar a rigidez do “Scrum ritualizado” é cultivar uma cultura de responsabilidade compartilhada pelo produto e pela qualidade.

❓ FAQ — Perguntas frequentes

Posso usar Scrum se minha gerência exige sprint-based reporting?

Sim. Uma abordagem prática é usar Kanban para execução e manter relatórios baseados em cadência para a gerência. Isso permite que o time funcione com fluxo enquanto a organização recebe os dados que precisa. Introduza métricas de fluxo (lead time, throughput) nos relatórios e traduza melhorias técnicas em impacto de negócio.

Se eu trocar para Kanban, preciso abandonar todas as cerimônias?

Não. Kanban não exige cerimônias rígidas, mas reuniões curtas e objetivas (standups diários, planning leve, retro) continuam úteis. O objetivo é reduzir cerimônias inúteis e manter apenas as que ajudam a remover impedimentos e melhorar fluxo.

Como convencer a liderança a investir em práticas técnicas (TDD, CI/CD)?

Apresente dados: mostre tempo de ciclo atual, custo médio de bug em produção e como automação reduz o custo médio por deploy. Pequenos experimentos com retorno rápido (por exemplo, configurar CI e reduzir regressões em uma área crítica) podem gerar buy-in para investimentos maiores.

Scrum é ruim para times grandes?

Não necessariamente. Scrum é usado com sucesso em grandes organizações, especialmente quando combinado com práticas técnicas e coordenação entre times (Scrum of Scrums, por exemplo). O problema aparece quando a coordenação é feita às custas da execução técnica e do fluxo.

O que eu faço se o PO briga comigo por não seguir o plano do sprint?

Converse com foco em valor. Explique que o objetivo não é quebrar previsibilidade, mas entregar valor de forma contínua e previsível. Traga métricas de lead time e qualidade e proponha um acordo sobre como priorizar trabalho emergente vs planejado.

Existe uma “receita” ideal para todos os times?

Não. Cada time precisa adaptar práticas ao contexto. O importante é ter clareza sobre objetivos (reduzir lead time, aumentar qualidade, melhorar previsibilidade) e escolher práticas que suportem esses objetivos. Experimente pequenos passos e meça impacto.

📝 Conclusão: escolhe a ferramenta pelo problema

Em resumo: o problema que eu tenho com Scrum não é o framework em si, mas a forma como ele tem sido aplicado em muitos lugares — burocrático, ritualizado e, às vezes, desconectado da engenharia. Quando você coloca cerimônias e papéis acima da qualidade técnica e do fluxo de valor, você perde o propósito do desenvolvimento ágil: inspecionar, adaptar e aprender rapidamente.

Minha proposta prática é combinar princípios técnicos do Extreme Programming (TDD, CI, pair programming), gestão de fluxo com Kanban e maturidade cultural para responsabilidade compartilhada. Se a sua organização exige relatórios baseados em sprints, use uma abordagem híbrida e traduza ganhos técnicos em métricas de negócio.

Quero muito saber: você concorda comigo? Tem experiências que contradizem tudo isso? Conta aqui nos comentários da comunidade e compartilha este texto com quem insiste em aplicar frameworks com base em hábitos e não em resultados. Obrigado por chegar até aqui.

E se você curtiu, compartilha esse texto e vamos trocar experiências.

Obrigado e até a próxima