Principle Tie-Breakers: When SAFe Principles Conflict

SAFe's ten principles have no ranking, unlike the Agile Manifesto's four values. This tiebreaker method uses an A3 process and a named-decision test.

Two correctly-applied SAFe principles can point at the same decision and demand opposite answers, and the framework’s own canon has no principle tie-breaker for when SAFe principles conflict this way. A Release Train Engineer who has memorized all ten Lean-Agile principles by name hits the same wall a Product Owner does: knowing what each principle means doesn’t say which one governs when Take an Economic View and Assume Variability and Preserve Options both apply to the same call. The Agile Manifesto that SAFe descends from solved this with an explicit ranking. SAFe dropped it.

---

Where this article sits

Journey stage 2 of 7: Use Cases

readiness → use-cases → roi → pilots → kpis → operationalize → scale

this articlelinkedjourney stagepillar

Your trail so far

The articles you visit light up on this map.

Why SAFe’s Flat Principle List Needs a Tiebreaker

SAFe’s ten Lean-Agile principles publish as a flat, unranked list, so when two of them correctly apply to the same decision and point in different directions, the framework gives no rule for which one governs: a gap the Agile Manifesto it descends from didn’t leave open. That’s not a minor omission. It’s the difference between a document that tells a team how to act under pressure and one that tells a team what matters without saying what to do when two things that matter collide.

The Agile Manifesto’s Built-In Ranking

The Agile Manifesto states its priorities as four explicit trade-offs, not four equal virtues: Individuals and Interactions over processes and tools, Working Software over comprehensive documentation, Customer Collaboration over contract negotiation, and Responding to Change over following a plan. Each pairing names both sides and then ranks them: the manifesto doesn’t claim processes or documentation are worthless, only that they lose when they compete with the item on the left. The closing clause states it plainly: while there is value in the items on the right, the manifesto values the items on the left more.

That clause is doing structural work most readers skim past. It’s a built-in tiebreaker, not a passing sentiment; when Working Software and comprehensive documentation compete for the same hour of a developer’s day, the manifesto has already told the team which one wins Working Software (Agile Alliance). Twelve supporting principles elaborate on Customer Collaboration and Responding to Change without ever re-opening that ranking. A team reading the manifesto in 2001 or today gets both the values and the rule for resolving them when they compete.

SAFe’s Flat List: What Got Dropped in the Translation

Dean Leffingwell’s ten SAFe Lean-Agile Principles trace directly to that Agile lineage, but the translation drops the ranking the source document carried. SAFe’s own documentation presents Take an Economic View, Apply Systems Thinking, Assume Variability and Preserve Options, and the seven principles that follow as a numbered list, and the numbering is sequential, not hierarchical; principle nine doesn’t defer to principle one when the two disagree on a specific call Apply Systems Thinking (Scaled Agile Framework).

The practical consequence shows up the first time two of the ten are both genuinely in play. A team can hold Take an Economic View and Assume Variability and Preserve Options as equally true; and it still has no rule for which one governs a live sequencing decision, because SAFe’s canon documents what each principle means without ever saying which one wins when both are correctly invoked on the same call. In SAFe 6.0’s current framing, the ten principles function as tenets that inspire practices, not as an ordered decision procedure, which is precisely why the gap persists across every version of the framework rather than closing with each revision.

The Gap in Practice: When Two Principles Both Apply

The gap emerges as a specific, recognizable moment: a Product Owner or Release Train Engineer has two principles open on the table, both correctly describing the situation, both arguing for different actions, and no page in the framework to turn to. Naming that moment precisely matters more than naming the principles involved, because the moment repeats across dozens of principle pairs; Take an Economic View against Preserve Options, Apply Systems Thinking against Decentralize Decision-Making, Organize Around Value against a locked cadence commitment.

Broader agile guidance recognizes the same trade-off logic without resolving it any more directly than SAFe does. The Agile Practice Guide, published jointly by the Project Management Institute and Agile Alliance, frames agile values as context-dependent trade-offs a delivery team negotiates case by case rather than a fixed hierarchy; useful for describing that trade-offs exist, silent on which one wins a specific collision Agile Practice Guide (Agile Alliance). That silence is exactly the space a structured resolution method has to fill, and it’s the space the rest of this guide builds a method for.

Management literature outside SAFe has already shown what an explicit ranking looks like when one gets built in. Vijay Govindarajan and Chris Trimble’s three-box approach, published in Harvard Business Review, assigns explicit priority across three competing demands on the same organization at once, manage the present, selectively let go of the past, create the future, rather than leaving managers to weigh all three as equally urgent (Harvard Business Review). McKinsey’s earlier Three Horizons model tried something similar by ranking innovation bets across near-, mid-, and long-term horizons, and Harvard Business Review’s Steve Blank argued in 2019 that the model has aged out precisely because it no longer gives teams a granular enough rule for choosing between horizons that now shift faster than the framework accounts for Steve Blank (Harvard Business Review). Both cases make the same point from opposite directions: an explicit ranking is worth building, and it goes outdated the moment it stops matching how fast the underlying conditions actually move. SAFe’s ten principles never had a ranking to go outdated in the first place.

---

The A3 Process: A Structured Method for Resolving Principle Conflicts

The A3 process, documented by John Shook in Managing to Learn, gives a Release Train Engineer a structured way to resolve a genuine principle collision in one sitting rather than escalating it to whoever holds the most authority in the room. Shook’s Lean Enterprise Institute book is explicit that the A3 is a process to solve problems, gain agreement, manage, mentor, and lead; deliberately not a report template a manager fills in after a decision has already been made (Lean Enterprise Institute).

The A3’s Five Parts, Applied to a Principle Conflict

Mapped onto a stuck principle decision, the A3 runs through five parts in order: a problem statement that names the decision itself, not the disagreement about it; each principle’s claim written out separately, in its own terms, without either side pre-compressed to fit the other; root-cause analysis of why the two principles disagree in this specific instance rather than in the abstract; a countermeasure that the team commits to; and a follow-up check that established whether the countermeasure actually resolved what the root-cause analysis found.

Writing all five parts down changes what the conversation produces. A Release Train Engineer working a Take-an-Economic-View-versus-Preserve-Options collision doesn’t start by picking a side: the problem statement forces the team to agree on what decision is actually stuck before either principle’s claim gets written. Root-cause analysis on a principle conflict most often surfaces an assumption neither side has said out loud: an estimate of cost of delay that one side treats as settled and the other treats as guesswork. The countermeasure and follow-up check turn that surfaced assumption into a decision the team can revisit on a fixed date rather than a conclusion handed down once.

Why the A3 Beats Escalating to Authority

Escalating a principle collision to whoever has the most authority in the room produces a ruling, not a resolution, because the person ruling almost never has visibility into both principles’ claims at the level of detail the team does. Shook’s account is specific on this point: the A3 process takes two, at minimum, because it’s built to force both sides of a disagreement into the same document rather than let one side’s perspective dominate before the other side has spoken.

An authority-based ruling resolves the immediate question and leaves the reasoning in the room where it was decided. The next Release Train Engineer who hits the same Take-an-Economic-View-versus-Preserve-Options collision on a different Program Increment starts from zero, because nothing about how the first decision was reasoned through persists past the meeting that made it. An A3 produces the opposite outcome by design: the document is the artifact, and the artifact outlives the meeting.

Where the A3 Comes From: Toyota, Not Software

The A3 process predates software delivery entirely and originates in Toyota’s own management practice, which is part of why it transfers cleanly to a principle collision that has nothing to do with code. Shook developed the A3 as a management discipline for the kind of structured problem-solving Toyota expected from every engineer and manager, long before Lean-Agile principles or SAFe existed as a category.

That origin matters for how a Release Train Engineer should treat the method. An A3 isn’t a framework invented to patch a gap SAFe left behind: it’s inherited management discipline that happens to fit the gap precisely, because both the A3 and SAFe’s Lean-Agile principles trace back to the same Toyota-influenced lineage of management thinking. A team adopting the A3 for principle collisions isn’t bolting on new process; it’s using the discipline the principles themselves already descend from.

---

Making the Tiebreak Reasoning Visible: The NUMMI A3 Mandate

A principle tiebreak decision needs to be written down because an unwritten decision can’t be coached, challenged later, or reused the next time the same two principles collide: a lesson Toyota’s NUMMI plant demonstrated with equipment shutdowns years before anyone applied it to Lean-Agile principles. The mechanism that produced the result is worth naming precisely, because it isn’t authority: it’s visibility.

Fumitaka Ito’s A3 Mandate at NUMMI

Jeffrey Liker and Gary Convis document the case in The Toyota Way to Lean Leadership: NUMMI plant president Fumitaka Ito required an A3 on every equipment shutdown, not to generate paperwork but specifically to make each engineer’s thinking process visible to the rest of the organization Fumitaka Ito (Lean Enterprise Institute). Body-shop engineers had been solving individual breakdowns competently for years without that mandate: the plant kept running. What Ito’s requirement changed wasn’t whether problems got fixed, but whether the reasoning behind each fix became something the rest of the team could see, question, and build on.

Ito came out of finance, not manufacturing, and Liker and Convis’s account treats that as relevant rather than incidental: someone outside engineering’s normal chain of authority was the one who noticed that competent individual fixes weren’t compounding into organizational improvement. The gap he identified wasn’t a skills gap. It was a visibility gap.

What the Uptime Numbers Show

The reported outcome of Ito’s mandate was body-shop uptime climbing over time toward the levels Toyota’s Japanese plants were already achieving: a gap NUMMI had struggled against for years despite having motivated, capable engineers on every shift. The mandate didn’t add headcount or new equipment. It added a requirement that the reasoning behind each shutdown fix get written where the next engineer could read it.

That distinction is the transferable lesson for a Release Train Engineer weighing a principle tiebreak: the uptime gain didn’t come from any single A3 solving a uniquely hard problem. It came from every A3 after the first one starting from what the previous one had already established, instead of re-deriving the same root cause from nothing. A principle collision resolved once and never written down forces the next team through the same reasoning from scratch. Visible reasoning is what let Ito’s plant compound instead of resetting with every shift change.

Why an Unwritten Tiebreak Doesn’t Compound

A hallway conversation that resolves a Take-an-Economic-View-versus-Preserve-Options standoff and gets announced as a done decision produces the same immediate outcome as a written A3: the sequencing call gets made either way. What it doesn’t produce is anything the next Release Train Engineer can inherit six months later when the same two principles collide on a different Program Increment.

An unwritten tiebreak can’t be coached, because there’s no artifact for a more experienced RTE to point to and explain what made the reasoning sound. It can’t be challenged later, because there’s nothing to challenge; only a memory of what someone decided, which degrades and gets contested the way any unrecorded decision does. And it can’t be reused, which is the costliest gap: the same principle pair will collide again, on a different Program Increment, in front of a different team, and the reasoning that resolved it the first time is unavailable to whoever hits it next.

---

A Worked Conflict: Economic View Versus Preserve Options in a Sequencing Call

A Weighted Shortest Job First calculation that wants a batch locked and started this Program Increment, set against Assume Variability and Preserve Options arguing to defer the same call until uncertainty is smaller, is a genuine SAFe principle conflict: not a case of either principle being applied wrong. Both sides of this collision are correctly reasoning from the principle they’re invoking; the disagreement is real, and it’s exactly the kind the A3 process from the sections above is built to resolve.

Stating Both Principles’ Claims on the Same Decision

Running the collision through the A3 structure starts with the problem statement: which specific sequencing call is stuck, stated as a decision rather than as a disagreement between two camps. From there, each principle’s claim gets written out on its own terms before either one gets weighed against the other.

WSJF’s Claim: Lock the Batch Now

Weighted Shortest Job First scores the item’s cost of delay against its job size and returns a number that argues for starting the work this Program Increment; every additional Program Increment the batch waits costs the organization the value it would have delivered, calculated and comparable against every other item competing for the same capacity. WSJF’s claim isn’t a preference; it’s an output of an explicit calculation the team already trusts for every other prioritization call on the board.

The claim carries real weight precisely because it’s quantified rather than argued. When a WSJF score is high, the case for starting now doesn’t rest on urgency someone feels: it rests on a number the same team would accept without argument if uncertainty weren’t also in the picture. That’s what makes this a genuine collision rather than a case of one side simply being wrong: the WSJF score is doing exactly what it’s supposed to do.

Preserve Options’ Claim: Defer Until Uncertainty Drops

Assume Variability and Preserve Options argues the opposite direction from the same facts: locking a batch now, while the uncertainty behind the WSJF estimate is still wide, commits capacity based on a cost-of-delay number that itself might be wrong. The principle’s claim is that early decisions in variable conditions are often wrong decisions, and that keeping the batch open a little longer costs less than committing capacity to an estimate that later turns out to be off.

This claim also isn’t a preference: it’s the same discipline that justifies set-based design everywhere else in SAFe, applied here to a sequencing call instead of a technical architecture choice. The tension is specific and mechanical: WSJF assumes its inputs are trustworthy enough to act on now; Preserve Options assumes the same inputs are trustworthy enough to wait on, but not yet reliable enough to commit against.

The Countermeasure: Shrink the Batch Instead of Picking a Side

Root-cause analysis on this collision usually shows an assumption neither side stated explicitly: an unspoken belief about how expensive the delay actually is, set against an equally unspoken belief about how expensive being wrong would be. Once that assumption is named on paper instead of left implicit in each side’s argument, the collision stops looking like a choice between two principles and starts looking like a missing piece of information.

The countermeasure pattern that resolves most of these collisions doesn’t pick a side at all: it reduces the batch size. Instead of committing the full item this Program Increment or deferring the whole thing, the team sequences only the smallest slice that produces the missing information: a spike, a limited vertical slice, a single high-uncertainty component isolated from the rest of the batch. That slice satisfies WSJF’s claim by starting now, and it satisfies Preserve Options’ claim by committing the minimum capacity necessary rather than the whole estimate. Batch-size reduction doesn’t dissolve every Take-an-Economic-View-versus-Preserve-Options collision, but it resolves the specific version driven by uncertain cost-of-delay estimates, which is the version that recurs most often across Program Increment boundaries.

Writing the Rationale Down

Closing this collision the way the NUMMI case closes its equipment shutdowns means writing the resulting rationale down where the rest of the train can see it: the specific sequencing call, both principles’ claims as stated, the assumption root-cause analysis emerged, and the batch-size countermeasure the team committed to. That record is what makes the next Take-an-Economic-View-versus-Preserve-Options collision on the same train faster to resolve than this one was.

Without that record, the next Product Owner who hits the same collision on a different epic starts the argument from nothing, the same way an unwritten hallway decision forces every future NUMMI shift to re-derive a shutdown fix from scratch. With it, the team has a pattern on file, reduce batch size before picking a side, that shortens the root-cause step the second time a WSJF score and a Preserve-Options argument land on the same table.

---

Before You Escalate: Confirming the Standoff Is Real

Before committing leadership time to an A3 session, a Release Train Engineer needs a fast way to establish the standoff is genuine rather than one principle simply going unapplied and dressed up to look like a collision between two. The test is structural, and it takes minutes, not a meeting.

The Named-Decision Test

The Named-Decision Test collides two well-applied principles that still point different directions on the same call: the WSJF-versus-Preserve-Options collision above is a straightforward example, because both sides were doing exactly what their principle asks. A false conflict looks similar from a distance but collapses under one question: for each side, can the team name one specific recent decision it actually changed?

A side that can’t name one isn’t a genuine claimant to the collision: it’s citing a principle without having practiced it, and dressing that gap up as a disagreement with the other side avoids the real problem instead of resolving it. Running an A3 on a false conflict wastes the session, because no amount of root-cause analysis fixes a principle nobody on that side has actually been applying.

Signal	Genuine conflict	False conflict
Named-decision test	Each side points to one specific recent call it changed	One side can’t name a call it changed
What the gap actually is	Two correctly-applied principles, same decision, opposite direction	One principle cited but not practiced
Right next step	Run the A3 process	Route to the Principle-Practice Diagnostic
What an escalation meeting fixes	The standoff itself	Nothing: the adherence gap survives the meeting

Sending Adherence Questions Elsewhere

Confirming whether a team is actually applying a principle at all is a different question from resolving two correctly-applied principles that disagree, and it has a different answer than an A3 can provide. That question belongs to the cluster’s Principle-Practice Diagnostic, which exists specifically to test adherence rather than repeat that test inside every piece of tiebreak guidance.

Running the diagnostic first, before convening an A3 session, saves the leadership time a resolution meeting would otherwise waste on a side that was never really applying the principle it claims to be defending. Once both sides pass the named-decision test above, the standoff has been established as real, and the A3 process from the earlier sections applies exactly as written; problem statement, both claims, root-cause analysis, countermeasure, follow-up check.

---

Summary

The gap the Agile Manifesto closed with an explicit ranking is the same gap SAFe’s ten Lean-Agile principles leave open, and the A3 process, inherited from Toyota rather than invented for SAFe, is what fills it without requiring the framework to publish a ranking it never had.

The A3 Is the Adjudication Rule SAFe’s Canon Doesn’t Publish

SAFe’s principles were never going to get an explicit “X over Y” ranking the way the Agile Manifesto did, because the ten principles describe different, often non-comparable dimensions of a system, economics, flow, decentralization, cadence, rather than four competing values on a single axis. That’s a structural reason the ranking is missing, not an oversight anyone is likely to correct in a future SAFe revision.

What the A3 process supplies instead is a repeatable adjudication procedure rather than a fixed hierarchy, and that turns out to fit the problem better than a ranking would have. A published ranking would have to pre-decide every possible pairing of ten principles in advance, most of which will never actually collide in a given organization’s context. An A3 resolves the pairing that does collide, in the specific context where it collides, and leaves a written record that shortens the next collision between the same two principles. The Weighted-Shortest-Job-First-versus-Preserve-Options pattern worked through above, reduce the batch size rather than pick a side, is a first case; it will not be the last pairing a Release Train Engineer runs through this same structure, and each written A3 makes the next one faster, the way Ito’s mandate made each subsequent NUMMI shutdown faster to diagnose.

Test Before You Convene: Standoff or Adherence Gap

The single highest-leverage move in this entire method is the one that happens before any A3 gets opened: establishing, with the named-decision test, that both sides of the apparent standoff have actually been practicing the principle they’re citing. Skipping that test is the most common way an organization wastes a leadership session: not because the A3 process fails, but because it was never the right tool for what was actually an adherence problem wearing a collision’s clothes.

Applied in order, named-decision test first, A3 process second, written rationale third, the method turns what looks like an unresolvable philosophical disagreement between two correctly-stated principles into a short, repeatable procedure a Release Train Engineer can run inside a single working session. The record that procedure leaves behind is what separates an organization that gets faster at resolving Take-an-Economic-View-versus-Preserve-Options collisions from one that re-litigates the same argument every Program Increment: the difference, as Ito’s NUMMI mandate demonstrated years before anyone applied it to Lean-Agile principles, is whether the reasoning ever left the room it was decided in.