Scrum is often defended as a neutral framework: a lightweight process designed to help teams deliver value incrementally. That framing is false. Scrum is not neutral. It encodes assumptions about incompetence, risk avoidance, and managerial anxiety into process. It did not emerge because software engineering needed it. It emerged because organizations that do not understand software needed something they could point at, schedule, and control.

This article argues a simple thesis: Scrum exists primarily to shift responsibility away from decision-makers and onto process. It is not a prerequisite for building software. It is not correlated with excellence. And in many environments, it actively degrades engineering outcomes while providing psychological comfort to management.

If Scrum were necessary for complex software, the Linux kernel would not exist. Git would not exist. PostgreSQL would not exist. LLVM would not exist. None of these systems were built with daily standups, sprint planning, or retrospectives. They were built by engineers who understood their problem space and were allowed to work without ritualized micromanagement.

The existence of these systems is not an anecdote. It is a refutation.

The Historical Context Scrum Ignores

Scrum proponents often imply that pre-Agile software development was chaotic and dysfunctional. This is revisionist history. Software was built successfully for decades before Scrum. Operating systems, compilers, databases, networking stacks, and version control systems were created in environments that look nothing like modern Scrum teams.

What these environments shared was not process rigidity, but technical leadership. Clear ownership. Long feedback loops where appropriate and short ones where necessary. Engineers were trusted to decompose problems because they were hired for that competence.

Scrum reframes this history by pretending that complexity itself necessitates ceremony. That is incorrect. Complexity necessitates understanding, not rituals.

Scrum’s Core Assumption: Engineers Cannot Be Trusted

At its core, Scrum assumes that engineers left to themselves will drift, overbuild, or fail to deliver. This assumption is never stated explicitly, but it is encoded everywhere:

  • Work must be broken into artificial timeboxes.

  • Progress must be demonstrated performatively every two weeks.

  • Engineers must explain yesterday, today, and blockers daily.

  • Output must be estimated upfront despite estimates being known to be unreliable.

  • Work must be continuously visible to non-technical observers.

None of this improves software quality. It improves managerial visibility.

Scrum is surveillance disguised as collaboration.

If a team of competent engineers understands a problem, they do not need daily status rituals to make progress. If they do not understand the problem, Scrum will not fix that. It will simply produce well-documented failure.

Standups: Daily Status Theatre

The daily standup is presented as a synchronization mechanism. In practice, it is a status meeting with different branding.

The three questions format is revealing:

  • What did you do yesterday?

  • What will you do today?

  • What is blocking you?

These questions are not designed to solve problems. They are designed to expose deviations from expectation. They exist so that someone can notice if work is not progressing according to plan.

In competent teams, engineers communicate continuously and asynchronously as needed. They do not wait for a daily ritual to surface blockers. When something is blocked, it is addressed immediately. When progress is made, it is visible in code, not in spoken summaries.

Standups replace organic communication with compulsory performance.

Sprints: Artificial Deadlines Without Technical Meaning

Timeboxing work into sprints is one of Scrum’s most damaging ideas. Software does not decompose cleanly into two-week increments. Some problems take hours. Some take months. Forcing everything into sprint-sized chunks distorts design decisions.

Engineers begin optimizing for sprint completion rather than correctness. Technical debt is deferred because it does not “fit” the sprint. Architectural work is postponed because it does not demo well. Refactoring is avoided because it is difficult to estimate.

Sprints do not align with how software evolves. They align with how managers want to observe progress.

The irony is that Scrum advocates acknowledge estimation is unreliable, then require estimation anyway. This contradiction is never resolved. It is simply normalized.

The Product Owner Fiction

The Product Owner role is presented as a bridge between business and engineering. In practice, it often becomes a bottleneck with insufficient domain understanding and excessive authority over prioritization.

Most Product Owners cannot write code. Many cannot read it. Yet they are expected to decide what work is valuable and when it should be done. This separation institutionalizes misalignment.

In systems that actually work, decision-making authority is closer to the technical work. Engineers who understand constraints participate directly in prioritization. Trade-offs are made by people who feel their consequences.

Scrum inserts an intermediary who translates business pressure into tickets and then absolves everyone else of responsibility.

Backlogs: Infinite Lists as a Substitute for Thinking

The backlog is often defended as a dynamic prioritization tool. In reality, it becomes an ever-growing graveyard of ideas that will never be implemented.

Backlogs allow organizations to avoid hard decisions. Everything can be “prioritized later.” Nothing needs to be explicitly rejected. This creates the illusion of strategic clarity while guaranteeing execution confusion.

Strong teams maintain a small, intentional list of active work. Weak organizations maintain massive backlogs and call it planning.

Scrum encourages the latter.

Retrospectives: Process Introspection Without Power

Retrospectives are framed as continuous improvement. In environments where teams have real authority, they can be useful. In most Scrum implementations, they are performative.

Teams identify problems they cannot fix. Management nods. The same constraints remain. The same deadlines return. The same structural issues persist.

Retrospectives without power are therapy sessions for process victims.

Scrum and the Displacement of Accountability

One of Scrum’s most insidious effects is responsibility diffusion. When a project fails, no one failed. The sprint failed. The estimate failed. The process failed.

Scrum provides infinite language for failure that avoids naming decision-makers. This is not accidental. It is its primary utility.

Executives do not need to understand software if they can manage Jira. They do not need technical intuition if velocity charts exist. They do not need to trust engineers if process compliance can be audited.

Scrum is a governance layer for people who cannot evaluate engineering directly.

Why Kernels, Compilers, and VCS Systems Don’t Use Scrum

Large, successful open-source systems do not use Scrum for a reason. They rely on:

  • Clear maintainership

  • Code review

  • Long-term ownership

  • Merit-based authority

  • Asynchronous collaboration

  • Technical consensus

These systems handle complexity far beyond the average enterprise CRUD application. They evolve over decades. They survive contributor churn. They scale globally.

They do not need sprint planning.

The argument that “enterprise is different” is an excuse. Complexity does not require Scrum. Organizational distrust does.

The Certification Economy

Scrum persists because it created a certification industry. Scrum Masters must justify their existence. Coaches must sell transformation. Consultants must prescribe frameworks.

This ecosystem depends on perpetuating the idea that software development is inherently unmanageable without ritual. That idea is profitable. It is not true.

The more dysfunctional an organization is, the more Scrum artifacts it produces.

When Scrum Appears to Work

Scrum “works” in two scenarios:

  1. The team is already competent, and Scrum is ignored or lightly applied.

  2. The work is trivial enough that process overhead does not matter.

In the first case, success is attributed to Scrum despite occurring in spite of it. In the second, the system would have succeeded under almost any process.

Scrum is never the differentiator. Talent and clarity are.

What Actually Matters Instead

High-performing software teams share characteristics Scrum cannot manufacture:

  • Engineers who understand the problem domain.

  • Direct access between decision-makers and implementers.

  • Ownership over systems, not tickets.

  • Freedom to choose appropriate levels of formality.

  • Trust over surveillance.

These properties are cultural and structural. They cannot be retrofitted with ceremonies.

The Todo App Fallacy

Scrum is often justified for “complex” applications. Most teams using it are building basic web applications with well-understood patterns. Authentication, CRUD, APIs, dashboards.

These problems have known solutions. They do not require daily synchronization rituals. They require competent execution.

If a small team cannot build a todo app without sprint planning, the problem is not lack of Scrum. It is lack of skill or clarity.

Conclusion: Scrum as a Symptom, Not a Solution

Scrum is not the cause of bad software. It is the symptom of organizations that do not trust engineers and do not understand engineering.

It replaces judgment with process. Responsibility with ritual. Leadership with facilitation.

The existence of world-class software built without Scrum is not a coincidence. It is evidence.

If your organization needs Scrum to function, it does not need better Scrum. It needs better engineers, clearer goals, and the courage to remove managerial abstractions that exist only to protect themselves.

Scrum does not scale excellence. It scales mediocrity.

And mediocrity loves process because process cannot argue back.