ZeroBlockers vs SAFe

An Agile Release Train is, in SAFe’s words, “a team of Agile Teams aligned to a set of shared business and technology goals,” generally 50 to 125 people. Every 8 to 12 weeks the train meets, typically for two days, for PI planning, which SAFe calls essential. Teams leave with PI objectives that are “either committed or uncommitted,” and SAFe lists among the benefits of those objectives that they expose “dependencies that require coordination.” A planning board, regular sync meetings, and a Release Train Engineer keep track of the dependencies between planning events.

SAFe also advises having fewer dependencies. Its team guidance says teams are “designed to operate with the minimum possible constraints and dependencies with other teams.” Its guidance on organizing teams describes teams aligned to steps in a customer journey and platform teams that offer self-service.

The difference is what is required. SAFe calls PI planning essential and gives it a cadence, a format, and a role to run it. Removing dependencies is advice. The decoupling work goes into the same backlog as features and competes with them for capacity. Busy organizations do what is required first, so the train keeps planning around dependencies it meant to remove.

ZeroBlockers makes the removal the required part. Each Stream Team lists what it waits for, and leaders own working down that list. Each team owns research, delivery, and operation for its part of the customer journey, and changes its solution without reopening a shared delivery plan.

SAFe lists decentralized decision-making among its principles, and it also plans centrally. The two fit together because they cover different decisions. Its team guidance gives teams control over their work and iteration commitments, and teams write their own objectives. The ART backlog of features is prioritized by Product Management, while the plan for the PI is made jointly at PI planning.

So a team is free to choose its design, its tasks, and its pace. It is much less free to decide that a feature is the wrong one. At PI planning, teams commit to work that depends on each other’s features. When customers reject one of those features, every team that planned around it has to agree on the new work and trade capacity before anything changes. The code change is usually the quick part.

PI objectives describe business and technical goals, and an objective written as an outcome survives a dropped feature. A well-run train can make the change. The cost is the renegotiation, and it is paid every time a team learns something that affects another team’s plan.

Jeff Gothelf is co-author of Lean UX, which SAFe adopted in its version 4.5. Asked how the two fit together, he wrote: “The short answer is, I have no idea.” He asks how easily an organization can change direction after a discovery, pointing to the tension between learning and predictable delivery.

In ZeroBlockers the Stream Team decides what to build as well as how. The Product Team, the leadership group for the product, shares the strategy and agrees one to three outcome targets with each team every quarter, with no feature attached. A team changes its solution when the evidence changes and reports the decision in the Weekly Product Review, a 30-minute meeting between the Product Team and its Stream Teams. The Product Team does not approve solutions.

At PI planning, Business Owners give each team objective a business value from 1 to 10. At the end of the PI they score the value actually achieved. SAFe’s ART Predictability Measure “calculates the ratio of actual business value delivered in a PI to the planned business value,” and a reliable train is expected to land between 80 and 100 percent. It is one of six flow metrics SAFe defines, and the one Business Owners score at the end of every PI.

Consider a team that drops an objective after learning it would not help customers. Business Owners can credit that learning when they score actual value. Nothing in the measure asks them to, and the planned value stays in the ratio. A train judged on this number learns to protect the plan. SAFe also calls for customer and business outcome measures. In his 2026 critique, Jeff Gothelf puts the conflict bluntly: “SAFe optimizes for predictability, and predictability doesn’t react well to learning.”

The ZeroBlockers Weekly Product Review looks at customer outcomes and what each team learned. Each outcome metric has a health measure: faster setup, for example, must not come with more configuration errors. The pair shows when a gain in one place is costing customers somewhere else. Teams explain decisions to stop work as well as decisions to ship.

Each ZeroBlockers team lists everything it waits for: decisions, services, and shared code. Leadership works down the list. Most items fall under four of the six changes.

• Structure. Shape teams around parts of the customer journey, and accept some duplicated code where sharing it would tie two teams together.
• Governance. Give teams release authority when automated checks, fast rollback, and their delivery record support it. New teams and teams recovering from incidents get checks proportionate to the risk.
• Funding. Fund the team’s part of the customer journey for the year and review the investment every quarter. The budget allows solutions to change as the team learns.
• Scaling. Turn common recurring requests, such as an environment, a security check, or a legal template, into a self-service product. An Internal Product Team runs it, with the other teams as its customers.

The goal is that a routine change needs no shared feature plan. The published accounts of Amazon and DAZN show the kind of architectural work involved.

Dave Farley, co-author of Continuous Delivery, has worked with several clients that adopted SAFe, and says his direct experience of it is limited. He writes that release trains, “in practice they seem to me to, much more commonly, represent a plateau that halts team’s progress towards a more effective flow-based approach.”

Beijer Electronics’ transition account, presented by its product, engineering, and UX leaders, describes moving from SAFe to empowered product teams. Their presentation covers customer testing, product and engineering collaboration, trust, and technical debt.

Keep the strategy alignment, discovery, investment reviews, and engineering practices that work. Drop a coordination meeting only after the dependency it manages has gone.