Scrum is the Symptom, not the Problem

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.