Scrum é péssimo
Scrum e o “Agile” com A maiúsculo são amplamente criticados aqui como frameworks inchados e ritualizados, que geram excesso de reuniões, métricas de culto de carga e incentivos distorcidos, ao mesmo tempo em que fazem pouco para melhorar a entrega real de software. Muitos engenheiros relatam que o Scrum funciona mal para trabalho reativo ou de operações, grandes organizações e ambientes com várias equipas, e argumentam que os problemas atribuídos a “má implementação” são, na verdade, estruturais. Alternativas como Kanban, planejamento incremental leve, retrospectivas fortes e processos definidos pela equipa são vistas como mais eficazes quando combinadas com liderança competente, confiança genuína e foco em resultados em vez de teatro de processo.
Scrum na teoria vs. realidade
- Muitos comentadores distinguem entre o Scrum “de livro” e o que as empresas realmente fazem.
- Visão comum: o framework é leve no papel, mas é transformado numa burocracia rígida e hierárquica, com certificações, jargão e ferramentas (especialmente JIRA, SAFe).
- Alguns argumentam que essa inversão viola o “indivíduos e interações acima de processos e ferramentas” do Manifesto Ágil.
Excesso de reuniões e perda de produtividade
- Relatos recorrentes de engenheiros com apenas 3–4 horas/dia (ou menos) para trabalho real devido a cerimónias e reuniões de status.
- Sprints, daily standups, grooming, planejamento de PI e reuniões de “todos” muitas vezes se acumulam, especialmente quando as pessoas estão em várias equipas.
- Tentar limitar o tempo de reunião pode apenas deslocar as mesmas discussões para reuniões “fantasma” ou para o chat.
Story points, estimativa e velocidade
- Frustração intensa com story points: inflação, politização e confusão com tempo, apesar do mantra “points ≠ time”.
- As equipas muitas vezes inflacionam estimativas ou manipulam gráficos de burndown para parecerem bem, distorcendo o planejamento.
- Alguns veem valor nos points para planejamento dentro da equipa; outros defendem #noestimates ou simples contagem de tarefas/tamanhos de camisola.
Onde Scrum funciona vs. falha
- Funciona melhor para: pequenas equipas de produto focadas, consultorias que vendem sprints, ou equipas com muitos juniores que precisam de estrutura.
- Muitas vezes falha para: Ops/DevOps, trabalho reativo/on-call, infraestrutura, suporte, hardware e grandes organizações com mudança constante de prioridades.
- Os sprints tornam-se prazos de facto e incentivam dividir trabalho atômico em tickets artificiais e funcionalidades pela metade atrás de flags.
Alternativas e adaptações
- Muitos preferem Kanban para operações e trabalho contínuo de produto: fluxo contínuo, limites de WIP, menos cerimónias.
- Outros mencionam XP, desenvolvimento incremental ad hoc, ou o Shape Up da 37signals como mais próximos do espírito Ágil.
- Várias equipas usam efetivamente um híbrido: planejamento mínimo, incrementos curtos, poucas reuniões, entrega contínua.
Cultura, gestão e retrospecivas
- Tema forte: cultura ruim e liderança fraca tornam qualquer metodologia dolorosa; o Scrum apenas torna a disfunção visível.
- Críticas ao “agile de culto de carga” e a gestores inexperientes que usam processo/métricas como arma enquanto evitam responsabilidade real.
- As retrospecivas são vistas por alguns como a prática mais valiosa do Scrum; onde as equipas podem mudar honestamente o processo, o Scrum tende a funcionar melhor.