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

Felipe Vieira 7 de outubro de 2025 🇧🇷 Português 15 min read

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

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?

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:

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:

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:

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:

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:

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:

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

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

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.

Turbine seu Desenvolvimento com Prompts!

Você já sonhou em criar seu próprio aplicativo mas pensou que precisaria ser um gênio da programação? Chegou a hora de transformar esse sonho em realidade! Com as ferramentas no-code de hoje, você pode criar aplicativos profissionais sem escrever uma única linha de código.
Quero Profissionalizar meus APPs

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:

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”:

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:

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:

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