ZeroBlockers vs Scrum

The Scrum Guide is clear about who decides. “The Product Owner is one person, not a committee,” and anyone who wants the backlog changed can try “to convince the Product Owner.” It is equally clear about the condition: “For Product Owners to succeed, the entire organization must respect their decisions.”

The guide stops there on purpose. It calls itself “purposefully incomplete” and says the tactics for using it “vary widely and are described elsewhere.” Scrum.org and others publish further guidance. Someone still has to change feature-based budgets, settle what Sales has promised, and take decisions back from steering groups. A Product Owner cannot do any of that from the backlog.

ZeroBlockers assigns those changes to product leadership. A Product Team is the leadership group for one product: a Product Manager with the design, development, and marketing leads. It owns the vision, the strategy, the team structure, and the funding. A Stream Team is a small, persistent team of designers and developers that owns one part of the customer journey from research through live use. It chooses its solutions and decides whether to pivot, persist, or stop.

The two meet in the Weekly Product Review, a 30-minute meeting where each Stream Team reports its metrics, one thing learned, one decision made, and one decision needed. The Product Team checks that a team’s reasoning fits the strategy and can challenge it. It does not approve each solution. Anything material beyond a team’s scope, such as a promise made to a customer, goes to the Product Manager.

The roles change as well. A Stream Team has no Product Owner, because the product decisions a Product Owner makes are split: the team chooses solutions, and the Product Manager on the Product Team owns strategy and commitments outside the team. It has no Scrum Master, because process coaching comes from an Enabling Team shared across several teams. The team’s designer leads day-to-day discovery with the whole team involved.

The guide makes the Scrum Team responsible for “experimentation, research and development” in a single sentence. Its built-in feedback loop is the Sprint Review, where the team and its stakeholders inspect the result and “collaborate on what to do next.” How the team reaches customers, chooses between opportunities, or tests an idea before building it is left open. When nobody owns those steps, the backlog fills with requirements approved elsewhere, and the team’s job shrinks to building them.

ZeroBlockers makes them part of the working week.

• The team talks to customers every week, on a standing schedule that does not depend on the roadmap. Two or three interviews and one review of usage data is the default.
• The Product Team shares its strategy with the reasoning attached: the data behind it, what leaders concluded, and what they are betting on. A team that knows why can decide cases the strategy never covered.
• Each quarter a team proposes one to three outcome targets, such as the share of new accounts that finish setup, and agrees them with the Product Manager. Each target is paired with a health metric, a second measure such as error rate that reveals whether gains in one area are damaging another.
• Cheap tests come first. A prototype, or a sign-up page for a feature that does not exist yet, usually runs before production code. A written plan sets the success threshold before the result is known.

Forrester analyst Dave West named the pattern Water-Scrum-Fall in 2011. In his own summary, project planning and release management “continue to follow more-traditional approaches, meaning that Scrum adoption is limited to the development team.” The team “is presented with a detailed project plan and a set of requirements that it then works through.”

Survey data shows how common the organizational barriers are. In the 17th State of Agile Report (2024), 63% of team-level agile users followed Scrum. Asked what stops the business side from adopting agile, 47% of respondents cited general organizational resistance to change or culture clash, and 41% cited not enough leadership participation. Only 6% reported no barriers.

The pattern usually forms in three steps. Requirements are approved and funded before the team sees them, so the Product Backlog becomes a delivery list. The team iterates on how to build each item, since that is the only decision left to it. Finished work then joins a queue for a change board, a security review, or a release window.

Nothing in the guide asks for this, and nothing in it prevents it. Four of the six ZeroBlockers changes matter most here.

• Funding. Money attaches to a customer scope, such as onboarding or data management, and to an outcome. The solution can change without a new approval.
• Alignment. The team can change its solution within the agreed scope, and leadership handles commitments outside it.
• Governance. Release approval follows a team’s record. A team with automated checks and clean releases ships without asking. A new team, or a team that has just had an incident, gets closer checks until it earns that back.
• Scaling. An Enabling Team, one or two senior practitioners in a discipline such as research or testing, coaches teams, but it does not do the work for them, as it would in a Center of Excellence. A request that keeps recurring, such as a security check, becomes a self-service product run by an Internal Product Team.

Scrum’s events give the team set times to inspect and adapt. When a change takes days to build, a fixed Sprint holds decisions back. The team finishes early and waits for the next Planning, or learns something mid-Sprint and waits for the Review. ZeroBlockers replaces the Sprint with continuous flow, so inspection moves into the daily work. This is a change to Scrum, and a team that makes it should stop calling the result Scrum. Planning and improvement happen when the team needs them, without waiting for a Sprint boundary.

Team together, and coordinate as the work changes. The whole team works on one item at a time: a designer sketches while a developer prototypes and a teammate lines up customer interviews. Work in progress stays low and a blocker gets help the moment it appears. A short daily look at the board checks priorities and work in progress. Most coordination happens in conversation during the work, though distributed teams may need extra check-ins. Drop a meeting only once its job already happens somewhere else.

Improve every day. The team takes a few minutes at the end of the day while the friction is fresh, fixes what it can on the spot, and checks later whether the fix helped. A longer weekly session catches the patterns a daily conversation misses.

Plan continuously. The quarterly outcome target gives direction. The team chooses one small problem or experiment to work on next and defines what it needs to learn or achieve before moving on. Customer feedback can change that choice. The Weekly Product Review keeps leadership informed of results and decisions.

Finance must fund customer scopes in place of feature lists, stakeholders must give up some delivery promises, and managers must delegate solution decisions. Start with the one rule that blocks the team most often and that it cannot change itself: a budget rule, a release approval, or a queue for a shared service.

Keep empirical learning, a clear goal, cross-functional collaboration, a Definition of Done, and sound engineering.