Scrum is the Symptom, not the Problem
Critiques of Scrum in software teams quickly expand into a broader argument about who should control how software is built: managers and processes, or engineers with deeper product and business ownership. Commenters contrast good and bad implementations of Scrum, debate whether frameworks like SAFe and Jira-heavy workflows inevitably become micromanagement, and note that estimation, budgeting, and trust are the underlying pressures driving these systems. Several argue that real change requires either flatter, cross‑functional organizations or developers becoming founders and freelancers, while others maintain that some structured process is unavoidable in large, risk‑averse companies.
Scope of Scrum’s Problems
- Many argue Scrum is widely disliked by developers and mainly benefits managers by creating an illusion of metrics, estimation, and control.
- Others counter that Scrum works well for a substantial minority of teams, that there are “good” and “bad” implementations, and that critics overgeneralize from personal experience.
- Several note that Scrum predates the Agile Manifesto and was part of the Agile movement from the start; critics respond that, in practice, it often violates “people over processes.”
Implementation, Ceremonies, and Alternatives
- Experiences range from lightweight Scrum (short standups, realistic sprint commitments, peaceful focus time, valuable demos) to cargo-cult versions (long daily calls, arbitrary deadlines, heavy ritual).
- Some see Scrum as mini-waterfall with endless ceremonies; they prefer Kanban or very light processes and direct developer–stakeholder interaction.
- SAFe is frequently criticized as “waterfall by another name,” though a few say it can work tolerably in large enterprises.
Power, Ownership, and Business Alignment
- A recurring theme: developers lack real power and are treated as interchangeable cogs; processes exist to connect work to money and protect budgets, not to make engineers happy.
- One proposed “solution” is developers becoming founders or freelancers so they can control how they work.
- Others advocate multidisciplinary teams, more business context for engineers, and product roles that share “why” and outcomes, not just task lists.
- There is disagreement over whether devs or managers are more to blame for bad Scrum; some say devs dodge business responsibility, others say management imposes process instead of trust.
Process vs. People and Organization Design
- Several commenters argue Scrum fails when there is low trust; no process can fix that.
- Debates on centralized vs. distributed decision-making: distributed governance can stall change, but centralized power can ignore teams.
- Views diverge on big-design-up-front vs. iterative learning: some claim serious organizations need heavy upfront design; others say software’s uncertainty makes that ineffective.
Tools and Personal Coping Strategies
- Jira is often hated, but some say it works well when thoughtfully configured; the “problem is people, not processes/tools.”
- Individual responses include negotiating down ceremonies, quietly doing necessary work, or leaving for contracting/freelancing when process overhead and lack of ownership become intolerable.