Scrum in Practice: Concerns Analysis

 |  Writings

Scrum is often praised for its simplicity and adaptability, but when applied to non-trivial domains, novel products, its standard processes reveal significant gaps.

Below, I state the my key concerns with Scrum, and contrast Scrum’s theoretical approach with the realities of implementation.

Contents

Concerns

See also Martin Fowler's The State of Agile Software in 2018, Allen Holub's The Death of Agile presentation summary.

Knowledge Acquisition

For non-trivial products, half the effort should be knowledge acquisition: requirements, specification, modeling, not just delivery. Otherwise half of the effort would be fighting bugs, user dissatisfaction and rework.

Scrum Theory

  • Scrum acknowledges uncertainty through Knowledge Acquisition Stories (spikes), which are formal PBIs dedicated to research.
  • The framework assumes that most learning happens before a sprint (via backlog refinement) or just-in-time during execution (via conversations with the Product Owner).

Reality

  • Spikes Are Undervalued: Many teams treat spikes as secondary to "real work," leading to rushed research or skipped discovery.
  • Ongoing Learning Isn’t Accounted For: Scrum assumes that a brief refinement session or a quick chat with the PO resolves ambiguity. But in any business domain beyond CRUD, most questions can’t be answered without deep exploration—often spanning multiple sprints.
  • The 80/20 Problem: If 80% of effort goes into knowledge acquisition (domain exploration, requirements, modeling) and 20% into coding, Scrum’s focus on 'delivering increments' forces teams to invert priorities—sacrificing quality for velocity.
  • Scrum’s timeboxing pressures teams to prioritize 'deliverable' tasks over domain knowledge acquisition, even when the latter prevents costly rework.

Result:

Teams either ignore necessary knowledge acquisition (leading to product defects 1) or struggle to fit learning into rigid sprints, making progress feel sluggish.

Sprint Planning Meeting PBIs Decomposition

Sprint Planning assumes tasks can be broken down on the spot, but this is unrealistic for complex or novel work.

Scrum Theory

  • The Definition of Ready states that backlog items must be "sufficiently understood" before entering a sprint.
  • Task breakdown happens just-in-time during Sprint Planning Meeting, with the PO available to clarify ambiguities.

Reality

  • Complex Work Defies Predictability: For CRUD apps, breakdowns are easy. But beyond that, tasks cannot be meaningfully decomposed until after domain exploration, requirements, experimentation, modeling.
  • "Sufficiently Understood" is a Fantasy: Many teams fake readiness to meet Scrum’s expectations, leading to last-minute replanning or failed sprints.
  • The Product Owner Bottleneck: The assumption that the Product Owner can instantly resolve deep technical or domain-specific questions is naïve. Often, answers require domain experts, prototypes, or external research—none of which fit neatly into a sprint.

Result

Teams either waste time in planning trying to force breakdowns or commit to unrealistic work, leading to burnout, failed sprints work defects, and ultimately to products being late to market and of poor quality.

The Mini-Waterfall Paradox

Scrum Theory

  • Sprint Execution must avoid "mini-waterfalls" (sequential analysis -> design -> implementation phases).
  • Work should be organized "opportunistically" and "just-in-time" during the sprint.
  • All uncertainty can be resolved through Daily Scrums and ongoing collaboration.

Reality

  • No software is built without engineering phases: functional software requires explicit requirements, modeling, implementation. These are inherently sequential dependencies - you cannot write tests (A/TDD) with no 100% conscious explicit deterministic specifications (DDD, use cases, user stories, BDD/Gherkin scenarios, SbE, Design by Contract, UML modeling).

  • The hidden Waterfall: teams either cut corners (build without analysis -> ???% unconscious implicit determinism -> defects), secretly do waterfall (do analysis/design first, but hide it to comply with Scrum dogma), fail repeatedly (discover gaps too late, miss sprint goals, even more defects, inevitable rework);

Result

  • 50-70% rework rates in non-trivial domains, late in production (IEEE studies)
  • False velocity metrics (teams "complete" stories that later require massive revisions)
  • Flawed architecture and design make software unable to accommodate incoming flow of product changes, require a massive code throwaways (rewrites)

Product Owner Capacity

Scrum Theory

Ongoing conversations with the Product Owner ensure clarity during the sprint.

Reality:

  • Many Product Owners lack the expertise requirements Scrum imposes on them, turning them into mere message relays rather than decision-makers.
  • On top of expertise some questions require days (or weeks) of investigation, stalling progress.

Research Stories Solve All Uncertainty

Scrum Theory

Dedicated research stories (spikes) handle exploration.

Reality

  • Teams often skip spikes to meet delivery pressure.
  • Many spikes lack clear outcomes, turning into endless rabbit holes.

The Definition of Ready Prevents Ambiguity

Scrum Theory

PBIs must be "ready" before entering a sprint.

Reality

  • In beyond-trivial domains, defining readiness is impossible without clear requirements for outputs, that requires domain exploration and software modeling.
  • Trying to guess strict "ready" criteria with no actual engineering activities suggested to clarify the task at hand it leads to wrong criteria in turn again leading to poor quality.
  • Without these activities, 'readiness' becomes a checkbox exercise, masking unresolved complexity.

Here's the additional section for your rewrite, maintaining your existing structure and style while incorporating the new analysis:

The Takeaways

Scrum’s core weakness is that it tries to replace the actual engineering approaches with managerial approaches that alone are not sufficient to deliver software.

It expects a huge critical capacity from a Product Owner not relating that such idealistically described person is not possible to find in reality. It imposes vast and at the same time vague expectation on Development Team at the same time not letting it do its engineering work in requirements and modeling, limiting it instead to vague User Stories or the same vague PBIs.

For simple, well-understood problems (like CRUD apps) where basic knowledge is enough, it works with average Product Owners and Development Teams. But beyond that Scrum's assumptions break down.

To countermeasure these issues, any managerial approach, not only Scrum must be paired with a real software engineering methods. For more details see my reviews of Essential Scrum, Writing Effective Use Cases, User Stories Applied books.

Footnotes

  1. No code can be written without 100% determinism. It is your choice if your programmers' determinism is either implicit, unintended and unconscious, not explicitly conveying what stakeholders want, in most cases leading to defective code or explicit, intended and conscious, leading to zero-defects and doing exactly what stakeholders need from the first time. ↩