SAFe Principles

28 MIN READ

Named Anti-Pattern Catalog: 30 SAFe Principle Anti-Patterns

Thirty named SAFe anti-patterns sorted into five failure dimensions instead of ten principles, each paired with its mechanism and a named remediation.

Most SAFe anti-patterns get named the moment someone notices they went wrong: one team, one ceremony, one bad Sprint. This named anti-pattern catalog groups SAFe principle anti-patterns differently: portfolio-level failures cluster in five predictable dimensions, and the fix that works for one entry in a dimension usually works for the next.

Where this article sits

Journey stage 4 of 7: Pilots

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

this articlelinkedjourney stagepillar

Your trail so far

The articles you visit light up on this map.

How This Anti-Pattern Catalog Is Organized

An anti-pattern is a process that initially looks like an effective response to a problem but consistently produces worse outcomes than doing nothing, and this catalog groups thirty SAFe-context anti-patterns by the failure dimension they violate rather than by which of the ten Lean-Agile Principles each one traces back to. The danger sits in the opposite direction from what the word “anti-pattern” suggests: most of these entries look like discipline, structure, or good process to the people running them, which is why they persist for years inside otherwise healthy transformations.

Agile Alliance’s Definition: Looks Good at First, That’s the Danger

Agile Alliance defines an antipattern as a generally used process, structure, or pattern of action that initially appears to give an effective response to a problem, but turns out to give more bad response than good (Agile Alliance). Andrew Koenig coined the term in a 1995 article, describing something that looks like a pattern but substitutes a solution that only appears to solve the problem for one that actually does Andrew Koenig (Martin Fowler). That distinction separates an antipattern from an ordinary myth or a plain bad practice: a myth gets debunked once someone checks the facts, and a bad practice rarely fools anyone twice. An antipattern survives because the people running it get a plausible-looking result, a filled Portfolio Kanban board, a funded epic, a completed retrospective, and read that surface result as proof the approach works. Fowler’s own gloss on Koenig adds the detail that makes a catalog like this one necessary: the same solution can be a genuinely good pattern in one context and an antipattern in another, so no entry here is universally bad: each is bad under specific, nameable conditions (Martin Fowler). Consulting research analyzing large-scale technology transformations backs the practical shape of that claim: antipatterns emerge across a narrow set of recognizable operational categories rather than showing up as one-off mistakes scattered randomly across a portfolio (McKinsey). That clustering is the reason a catalog organized by dimension outperforms a catalog organized by principle.

Why This Catalog Borrows a Peer-Reviewed Taxonomy Method

This catalog borrows its organizing method directly from Taibi, Lenarduzzi, and Pahl’s peer-reviewed Microservices Anti-Patterns Taxonomy, which clusters entries by the failure dimension they violate instead of listing them as one undifferentiated set Microservices Anti-Patterns Taxonomy (Taibi, Lenarduzzi, and Pahl, CLOSER 2018). The paper was published at CLOSER in 2018 and has since accumulated roughly 94 citations, largely because it solved a real diagnostic problem: a flat list of named failures forces a reader to scan every entry to find the one that matches their symptom, while a hierarchical structure by failure dimension lets a reader jump straight to the cluster that matches what’s actually going wrong (Taibi, Lenarduzzi, and Pahl). Applying that same logic here rules out the obvious alternative organization: one section per SAFe Lean-Agile Principle. Each of the ten principles already has its own dedicated page describing what violating that specific principle looks like; re-deriving ten failure modes here would repeat that material rather than add to it. Clustering by dimension instead, funding and strategy, portfolio operations, lean governance, team ceremony, and metrics and goal-setting, groups entries the way a diagnosing reader actually experiences them: as a category of pain, not a principle number.

Dimension	Antipatterns Catalogued	Representative Entry
Strategy and Investment Funding	7	Annual Budget Lock-In
Agile Portfolio Operations	6	Portfolio Kanban as a Tracking Board Only
Lean Governance	5	Compliance Theater
Team Ceremony (Retrospectives)	3	Loudmouth
Metrics and Goal-Setting	6	Comparing Velocity Across Teams

Five clusters, not ten principle-shaped sections, is the direct consequence of borrowing a failure-dimension taxonomy instead of a principle-by-principle outline.

The Entry Standard: Name, Mechanism, Remediation

Every entry in this catalog commits to the same three-part standard: a name specific enough to recognize on sight, the exact mechanism that makes the antipattern look like a good idea, and a named remediation wherever one exists. A name matters because a vague warning like “governance is too heavy” gives a reader nothing to check their own portfolio against, while a name like Compliance Theater or Wheel of Fortune gives them something they can recognize on a Tuesday afternoon. The mechanism matters more than the name: stating that a Stage-Gate Process layers sequential approval back onto a flow-based system tells a reader exactly what to look for, where the label alone would not. Fowler’s original description of the discipline treats a remediation as valuable but optional: a good antipattern write-up should include a way out where one exists, but the absence of a fix doesn’t reduce the value of the warning itself (Martin Fowler). This catalog treats remediation more strictly: every dimension pairs its entries against a single named remediation vehicle, a problem-solving A3 built on the Plan-Do-Check-Act cycle, so a reader who recognizes their own situation in one of these thirty names also gets the method for fixing it, not just the label for what’s broken.

Strategy and Investment Funding Anti-Patterns

Seven named funding antipatterns recur across SAFe portfolios, funding projects instead of value stream capacity, annual budget lock-in, Investment Horizons misuse, miscalibrated Budget Guardrails, ceremonial Participatory Budgeting, Strategic Themes disconnected from execution, and HiPPO Prioritization overriding economics, and each is a checkable condition, not a vague complaint about “bad funding.” None of the seven require bad intentions. Every one is what happens when a legacy funding habit gets a Lean label and keeps its old behavior underneath (agility-at-scale.com).

Funding Projects Instead of Value Stream Capacity

Funding projects instead of value stream capacity means a portfolio allocates budget to individual initiatives with defined start and end dates rather than to the ongoing capacity of the value stream that will deliver them. The mechanism is familiar to anyone who has sat through a project-based finance review: a new initiative competes for a fresh budget approval, gets a temporary team assembled around it, and disbands that team the moment the project closes. It looks disciplined because per-project accounting maps straightforward onto existing finance controls and gives a clean line for ROI attribution: a controller can point at exactly what a dollar bought. The cost shows up downstream, not in the approval meeting. Teams that reassemble around every new project lose the tacit coordination that makes a stable team fast: the shared context about the codebase, the customer, and each other’s working style resets every time the roster changes. Value Stream Capacity Funding replaces that cycle with a standing allocation to the value stream itself, so the team stays intact and priorities move inside a stable structure instead of the structure reforming around every new priority. Portfolios that keep project-based funding after adopting SAFe’s other mechanics usually discover the mismatch only when they try to explain why velocity keeps resetting every quarter regardless of how experienced the individual engineers are.

Annual Budget Lock-In and Investment Horizons Misuse

Annual Budget Lock-In and Investment Horizons misuse are two related but distinct funding failures: one freezes the amount available for twelve months regardless of what changes, and the other misallocates that frozen amount toward the wrong point in time.

Annual Budget Lock-In

Annual Budget Lock-In sets a fixed budget once a year and requires an exception-approval process for any reallocation before the next annual cycle. The mechanism is a calendar mismatch: SAFe’s Program Increment cadence runs in roughly quarterly cycles built for adjusting course as market signals change, while the budget that funds those PIs only reopens once a year.

By the time a market shift is obvious enough to justify a funding change, the next legitimate opportunity to reallocate is months away, so teams keep executing a plan the market has already outdated. The budget cycle, not the market, ends up setting the priority: a portfolio can see the shift coming and still be structurally unable to respond to it before the annual review comes back around.

Investment Horizons Misuse

Investment Horizons misuse over-allocates funding to current operations while starving future opportunities of the investment they need to mature. SAFe’s Investment Horizons construct is meant to hold near-term, evolving, and new/emerging bets in separate funding bands precisely so the safest, best-understood horizon doesn’t quietly absorb the whole budget.

A portfolio that misapplies the construct looks financially productive on a spreadsheet, current operations post steady numbers, while its future pipeline of new business opportunities starves in the new/emerging horizon it was never actually given room to grow in. By the time current-operations revenue softens, there is nothing funded in the next horizon ready to replace it.

Guardrails, Participatory Budgeting, and HiPPO Prioritization

Budget Guardrails, Participatory Budgeting, and HiPPO Prioritization fail in three different directions, and each failure mode is a miscalibration of a legitimate mechanism rather than the mechanism’s presence or absence.

Budget Guardrails Set Too Tight or Too Loose

Budget Guardrails exist to give portfolio and value stream teams room to operate inside defined limits without requesting individual approval for every spend. Set too tight, the guardrail forces the same central-approval friction the mechanism was supposed to eliminate; teams escalate routine decisions because the boundary sits too close to normal operating variance. Set too loose, the guardrail removes discipline entirely, and spend drifts without anyone noticing until the numbers are already bad. Calibrating the boundary correctly requires watching actual variance in spend and adjusting the guardrail to match it, not setting it once at launch and leaving it fixed.

Participatory Budgeting Skipped or Ceremonial

Participatory Budgeting is meant to give the people closest to the work real input into where funding goes. The ceremonial version predetermines the allocation before the session starts and runs the collaborative meeting anyway, purely for the appearance of buy-in. Stakeholders who sit through a session that never changes an outcome learn quickly that their input doesn’t matter, and the genuine information that participatory processes are supposed to bring to light, where the real constraints and opportunities actually sit, stops flowing to the people making the decision.

HiPPO Prioritization Overriding Economics

HiPPO Prioritization, the Highest Paid Person’s Opinion, overrides economic sequencing tools like WSJF with executive preference. The economic tool doesn’t disappear; it gets kept as documentation, run after the real decision has already been made, so the portfolio can point to a defensible-looking process while the actual sequencing follows whoever has the most senior title in the room. Economic Prioritization only works as a discipline when its output is the decision, not a report justifying one made elsewhere.

Strategic Themes Disconnected from Execution

Strategic Themes disconnected from execution means the portfolio states its themes at the leadership level and funds a set of epics at the delivery level that don’t trace back to any of them. The mechanism is a gap in the funding chain: Strategic Themes get written into a strategy deck, but nothing forces the epics that later receive funding to demonstrate a link back to a specific theme before approval.

Once that link isn’t enforced, Strategic Themes stop functioning as a filter and start functioning as a slide; any epic can get funded on its own merits and then justified after the fact against whichever theme sounds closest to what it already does. A portfolio in this condition can point to an impressive-sounding strategy document and a completely disconnected set of funded work, and neither side of that gap shows up as a problem until someone tries to explain why the strategy never seems to change what actually gets built.

Agile Portfolio Operations Anti-Patterns

Six named operations antipatterns recur once a portfolio has Portfolio Kanban running day to day: the board reduced to a tracking dashboard, missing or ignored WIP limits, Epic Owners without accountability, funnel congestion, WSJF misapplication, and Value Streams drawn around organizational structure instead of flow. Each is a specific, checkable condition inside the mechanics of running the board itself, not a general complaint about slow portfolios.

Portfolio Kanban as a Tracking Board Only

Portfolio Kanban as a tracking board only means the board displays where every epic currently sits without any of its states carrying real decision-making authority. The columns exist, epics move between them, and status meetings reference the board; but no state transition actually triggers a decision. Moving an epic into “Analyzing” doesn’t force anyone to produce a Lean Business Case before it can move further, and moving it into “Implementing” doesn’t require the funding case to have cleared review.

Run this way, the board becomes an expensive dashboard duplicating information that a spreadsheet could show just as well, and the portfolio loses the entire point of Portfolio Kanban: making the flow of decisions visible so that stuck decisions get exposed, not just stuck work. A board full of epics that have technically “moved” gives leadership false confidence that the portfolio is progressing, when what has actually moved is a status label.

Missing WIP Limits and Unaccountable Epic Owners

Missing WIP limits and unaccountable Epic Owners are two failures at the same layer of the Kanban system: one governs how much enters, the other governs whether what enters actually gets driven forward.

Missing or Ignored WIP Limits

A WIP Limit caps how many epics can occupy a given state at once, forcing the system to finish work before starting more of it. Missing or ignored limits let epics enter the funnel and each subsequent state regardless of the board’s actual capacity to move them, so the number of epics “in flight” grows without any corresponding growth in throughput.

The consequence compounds over time rather than appearing immediately: each new epic added past the effective WIP limit slows every epic already in progress, because the teams delivering them are now context-switching across more concurrent work than they can hold. A portfolio can watch its Portfolio Kanban board fill up and mistake that growth for momentum, when it is actually the mechanism by which everything already on the board is getting slower.

Epic Owners Without Accountability

An Epic Owner is supposed to actively drive an epic through the Kanban; validating the hypothesis, coordinating stakeholders, and making the calls that keep it moving. Unaccountable Epic Owners exist on paper only: a name sits in the Epic Owner field, but no one checks whether that person is actually doing the work of driving the epic forward.

Epics with a named-but-inactive owner stall quietly, because nothing in the system distinguishes an epic being actively pushed from one that’s simply sitting with someone’s name attached to it. The fix is not adding another approval layer: it’s making Epic Owner activity, not just epic status, something the portfolio reviews on a cadence.

Funnel Congestion, WSJF Misapplication, and Org-Shaped Value Streams

Funnel congestion, WSJF misapplication, and Value Streams defined around organizational structure are three separate failures that produce the same symptom: work enters the system and rarely produces the value the portfolio expected. Funnel congestion happens when a portfolio can’t bring itself to cancel or deprioritize ideas once they’re written down: the funnel only ever grows, because saying no to an idea someone championed feels harder than letting it sit unfunded indefinitely. A funnel that never empties eventually can’t distinguish a genuinely promising idea from the hundred that are just occupying space.

WSJF Misapplication

WSJF divides Cost of Delay by job size to sequence work economically, and it fails in two specific ways: inaccurate inputs, where Cost of Delay estimates are guessed rather than grounded in actual business impact, and treating the score as a one-time calculation rather than a living number that gets revisited as conditions change. An epic scored six months ago under different market conditions keeps its old WSJF ranking indefinitely if no one re-scores it, which means the portfolio is sequencing today’s work using yesterday’s economics.

Value Streams Defined Around Organizational Structure

A Value Stream Boundary is supposed to follow how value actually flows to the customer, from the moment a need is identified through to delivery. Defining that boundary around existing organizational structure instead, drawing the value stream to match the org chart because it’s the path of least resistance, reintroduces the exact handoffs across department lines that Portfolio Kanban was designed to eliminate.

Every handoff across an org-shaped boundary reintroduces queueing delay: work waits for the next department’s capacity, not because the work itself takes that long, but because the boundary was drawn around who reports to whom rather than around how the value actually moves.

Lean Governance Anti-Patterns

Five named governance antipatterns recur once a portfolio wraps oversight around already-funded work, Stage-Gate Process reintroduced inside SAFe, committee-based prioritization replacing economic scoring, Compliance Theater, excessive approval layers, and Portfolio Guardrails set too rigid, and the five compound instead of standing alone.

Stage-Gate Reintroduction and Committee-Based Prioritization

A Stage-Gate Process reintroduced inside SAFe layers sequential approval gates back onto a system built to run on continuous flow, defeating the point of the flow it was layered onto. The pattern is familiar from an earlier era of digital transformation: organizations once ran a “bimodal” IT model, developing new capability quickly with agile methods while operating core systems the traditional way in parallel: a structure that looked pragmatic but that IT leaders eventually recognized required applying agile principles broadly rather than fencing them off into one lane (HBR/IBM). A reintroduced Stage-Gate Process repeats that same fencing-off instinct at the portfolio level: flow-based Lean Governance in one part of the process, traditional sequential gating bolted back on in another.

Committee-based prioritization compounds the same instinct, but the failure mechanics are a group’s, not one HiPPO’s: a steering committee substitutes collective judgment for WSJF’s economic sequencing, and that judgment is shaped by whoever spoke last in the room, whoever holds informal veto power over a rival’s initiative, or a horse-trading dynamic where members protect each other’s pet epics in exchange for support on their own. No single committee member owns the sequencing call, which means no single person is accountable when the sequence turns out wrong: a diffusion of responsibility a lone HiPPO override, for all its faults, doesn’t produce, because at least one name is attached to that decision. A committee that wasn’t consulted when a WSJF score was originally set has an added reason to distrust it: overriding a number nobody in the room helped calculate feels safer than defending one they had no hand in producing.

Compliance Theater and Excessive Approval Layers

Compliance Theater describes governance activity that consumes real time and attention but produces no actual insight or risk reduction: the status report gets filed, the checklist gets completed, and nothing about the underlying risk changes as a result. A broader catalog of common agile-adoption failures documents heavy, form-driven governance as one of the more frequently cited reasons transformations stall even after leadership formally commits to them (Agile Alliance).

Excessive approval layers add escalation points between a decision and its execution, and each additional layer adds delay without adding judgment: a second or third reviewer rarely catches something the first reviewer missed, but every layer adds calendar time waiting for the next person’s availability. An Approval Layer justified as extra scrutiny usually turns out, on inspection, to be extra latency wearing scrutiny’s name.

Why Rigid Guardrails Compound the Other Four

A rigid Portfolio Guardrail rarely fails alone. Layered onto a portfolio that has also reintroduced a Stage-Gate Process and let a steering committee override WSJF, the miscalibrated guardrail becomes a third checkpoint a single funding decision has to clear rather than a boundary a team operates inside without asking permission. Each checkpoint adds its own reviewer, its own meeting cadence, and its own chance to stall: a decision that clears the guardrail can still stall in committee, and a decision the committee clears can still wait on the next scheduled Stage-Gate review.

Stack all three together and a single funding decision passes through three separate points of friction instead of one clear bottleneck a leader could identify and remove. Each layer alone might be defensible; together they produce a decision that takes months to clear a system built to clear it in days, and no single person in the chain experiences themselves as the cause, because each checkpoint’s owner is only responsible for their own layer, not the cumulative delay across all three.

Retrospective Anti-Patterns: Wheel of Fortune, In the Soup, and Loudmouth

Aino Corry names three recurring retrospective antipatterns, Wheel of Fortune, In the Soup, and Loudmouth, and pairs each with her own fix, building on the discipline Norman Kerth formally named “Retrospective” in his 2001 handbook, Project Retrospectives: A Handbook for Team Reviews Team Reviews (Martin Fowler). Kerth’s book described a formal method for preserving the lessons from a project’s successes and failures; Corry’s three antipatterns describe the specific ways teams break that method without realizing they’ve broken it.

Wheel of Fortune: Skipping Straight to Actions

Wheel of Fortune happens when a team jumps from gathering data straight to deciding on actions, skipping the insight-generation step in between, so the actions it lands on are effectively random; sometimes useful, sometimes not, the way a spin of a wheel sometimes pays out and sometimes doesn’t. The team feels productive because it walked out with a list of things to do, but nothing connected those actions to a diagnosed cause.

Corry’s fix inserts an explicit insight step before any action gets decided: simple open discussion, Five Whys interviews, or Fishbone Analysis, applied to the data the team just gathered, so the actions that follow address a cause instead of a symptom that happened to be visible that day. Skipping this step is invisible in the moment: a retrospective that skips insight generation looks exactly like a productive one until the same problem resurfaces the following iteration with a different symptom attached.

In the Soup: Stuck on What You Can’t Change

In the Soup describes a team spending its retrospective discussing things it has no power to change, a hiring freeze, a vendor contract, a reorganization decided two levels up, and getting frustrated as the conversation goes nowhere. Energy spent debating something outside the team’s control produces no progress and leaves the group more discouraged than when the session started.

Corry’s fix sorts every item raised into three buckets: what the team controls directly, what it can influence indirectly, and “soup”: the things that fit neither category. The team accepts the soup items as a fact of the environment rather than a problem to solve in this meeting. It redirects the freed-up time to the items it can actually act on. Naming the soup out loud is itself part of the fix: once a frustration is labeled as outside anyone’s control, it stops eating time that could go toward something actionable.

Loudmouth: One Voice Blocking Shared Learning

Loudmouth describes a single participant interrupting constantly and telling long stories, which blocks the rest of the team from contributing and turns a group learning exercise into one person’s monologue. The behavior is rarely malicious, the loudmouth usually believes they’re adding value by sharing context, but the effect on everyone else in the room is the same regardless of intent.

Corry’s fix replaces open plenary discussion with formats that don’t depend on who talks fastest: small groups, paired conversations, or written and kinesthetic activities like sticky notes that let every participant contribute without competing for airtime. She pairs that structural change with private feedback to the loudmouth directly, addressing the individual behavior outside the group setting rather than trying to manage it live in front of the team. A retrospective redesigned around these formats produces input from everyone in the room, not just whoever spoke first and loudest.

Velocity Metric Anti-Patterns

Agile Velocity is the most widely used, and most widely abused, metric in Agile software delivery, and LeadingAgile documents five specific ways teams misuse it: setting targets for it, substituting it for percentage-complete tracking, assuming instantaneous maximum performance, projecting stretch goals through wishful thinking, and comparing it across teams as if it meant the same thing everywhere Agile Velocity (LeadingAgile).

Target-Setting and Percentage-Complete Substitution

Target-setting and percentage-complete substitution attack Agile Velocity from opposite directions: one distorts a real velocity number, the other invents a velocity number where none actually exists.

Setting Targets for Velocity

Setting a target for velocity turns a measurement into a goal, and teams under pressure to hit a number find ways to hit it that have nothing to do with delivering more value: story sizes creep upward so the same work counts for more points, or acceptance criteria loosen so stories close faster. Velocity Target Setting inverts the metric’s purpose; instead of measuring what a team actually delivers so the organization can forecast realistically, it becomes a number the team manages toward, which destroys its value as a forecasting input the moment the team starts optimizing for it.

Substituting Velocity for Percentage Complete

Percentage Complete Substitution happens when an organization relabels a linear progress-tracking metric, “we’re 60% done”, as velocity, to sound Agile without running proper time-boxed iterations underneath it. The number reported looks like velocity on a chart, but it isn’t measuring the same thing: real velocity counts completed, production-ready increments per iteration, while a percentage-complete estimate is a subjective judgment call with no iteration boundary forcing it to be tested against reality.

Instantaneous Maximum Velocity and Wishful-Thinking Projections

Instantaneous Maximum Velocity and Wishful Thinking Projection are two ways stakeholders overestimate what a team’s Agile Velocity will deliver, one at the start of a program and one throughout it.

Instantaneous Maximum Velocity

Instantaneous Maximum Velocity assumes a team performs at its steady-state best from day one, producing release plans that look achievable on a spreadsheet and immediately fall behind once real iterations start. New teams, and even established teams tackling unfamiliar work, need iterations to establish a stable pace; planning against the number a team might eventually reach, rather than the number it’s actually delivering now, sets the whole plan up to slip before the first PI even ends.

Wishful-Thinking Projections

Wishful Thinking Projection happens when stakeholders push a team toward a “stretch goal” by adjusting the estimates behind the plan rather than by improving the team’s actual delivery capacity. The forecast changes on paper; nothing about the team’s real throughput changes in the room. A projection built this way collapses the moment reality catches up with the spreadsheet, usually mid-PI, when it’s already too late to replan cleanly.

Comparing Velocity Across Teams: A Number That Means Nothing

Cross-Team Velocity Comparison rolls up numbers from teams working in different contexts, different Time-Boxed Iteration lengths, and different types of work, as if the resulting figure measured the same thing in every case. It doesn’t: one team’s story point is calibrated against that team’s own historical throughput, not against any external standard, so a “10” from one team and a “10” from another carry no comparable information whatsoever.

LeadingAgile’s underlying diagnosis cuts through all five abuses at once: a team that isn’t running genuine time-boxed iterations with production-ready delivery each iteration doesn’t have velocity at all: it’s reporting something else entirely, and that something is meaningless for forecasting or cross-team comparison, however confidently it gets presented in a portfolio review (LeadingAgile).

Goal-Setting Anti-Patterns: OKRs Layered Onto Big-Batch Delivery

OKRs, Objectives and Key Results, were invented by Andy Grove at Intel and popularized by Google’s well-publicized adoption in 1999, and SAFe’s own guidance opens its treatment of the framework with John Doerr’s description from Measure What Matters: a management methodology that helps ensure the company focuses efforts on the same important issues throughout the organization Measure What Matters (SAFe).

OKRs From Andy Grove to Google to SAFe

OKRs are a collaborative framework for establishing clear goals and measurable outcomes, built around an Objective that names the business outcome sought and Key Results that give measurable success criteria for tracking progress toward it Key Results (SAFe). Since their invention at Intel and their subsequent adoption at Google, OKRs have spread through the technology industry largely because the format is simple enough to explain in a sentence and specific enough to hold people accountable to. Within SAFe, the framework supports Core Value transparency and alignment between Enterprise and Portfolio strategy and the work Agile Release Trains actually deliver, and SAFe’s guidance recommends applying OKRs specifically to describe portfolio Strategic Themes.

SAFe’s Own Failure Condition, Quoted Directly

SAFe’s own guidance names the exact condition under which its recommended goal-setting framework becomes an antipattern, in its own words: “the benefits of OKRs will only be realized where planning and delivery are incremental,” and “enterprises still employing traditional development methods, with an upfront commitment to large batches of work, will often struggle to reap the benefits of OKRs” (SAFe).

That statement is a first-party admission, not an outside critique: the same framework guidance page that recommends OKRs for Strategic Themes also states plainly that the recommendation only holds once Continuous Feedback and incremental delivery are already in place. An organization that adopts OKRs while still committing upfront to Big-Batch Delivery gets the ceremony of goal-setting, quarterly Objectives, tracked Key Results, without the feedback loop that makes either one mean anything, because a batch that doesn’t ship until quarter’s end can’t generate the continuous signal an OKR review depends on.

The Same Framework, Good Pattern or Antipattern by Context

Inside incremental, feedback-driven delivery, OKRs work exactly as Grove and Doerr described them: a focusing mechanism that keeps effort aligned to the same important issues throughout the organization, with each Key Result checked against a real delivered increment at every review. Layered unchanged onto a delivery model that still ships in large, infrequent batches, the identical framework produces goals no one can meaningfully track between reviews, because there’s no delivered increment yet to check progress against. The precondition doing the work here is narrow: it isn’t agile maturity in general that OKRs need underneath them, it’s Continuous Feedback specifically: a cadence of delivered increments frequent enough that a Key Result’s progress actually moves between one review and the next instead of sitting flat until the batch finally ships.

That context-dependency is the catalog-wide lesson every dimension above ultimately points back to: none of these thirty entries are bad ideas in the abstract. Each becomes an antipattern only when a specific precondition, value stream capacity, an active Epic Owner, a genuine WSJF re-score, incremental delivery, isn’t actually in place underneath it.

The Escape Route: Remediating a Cataloged Anti-Pattern With an A3

That problem-solving A3, already established above as this catalog’s single remediation vehicle, consumed 75 to 80 percent of all A3 practice time at Toyota, more than the proposal, status-report, and strategic-planning types combined (Lean Enterprise Institute).

The Problem-Solving A3: 75-80 Percent of Toyota’s A3 Practice

The problem-solving A3 fits every entry catalogued above because it always states a clear, Quantified Gap, the current condition measured against a standard, and every antipattern in this catalog is, structurally, a violated standard. A missing WIP Limit is a gap against the standard the limit was supposed to enforce; a Loudmouth-dominated retrospective is a gap against the standard of shared participation Kerth’s method assumes.

Toyota’s own practice weights problem-solving A3s far above the other three types, proposal, status report, and strategic planning, precisely because most real organizational trouble shows up as a measurable gap against an existing standard rather than as a blank-page decision about the future (Lean Enterprise Institute). The Lean Enterprise Institute also publishes standard forms and templates for A3 problem solving directly, alongside standard work and value stream mapping templates, so a team doesn’t have to invent the document format from scratch before it can start applying the method (Lean Enterprise Institute).

The PDCA Spine: Plan, Do, Check, Act

Every problem-solving A3 runs on the same four-step spine, regardless of which of the thirty cataloged antipatterns it’s pointed at:

Plan; grasp the current situation and compare it against where you want to be, stating the gap in measured terms rather than as a general impression.
Do; implement the plan at the scope you defined, not a larger fix than the gap actually calls for.
Check; evaluate whether the change produced the effect the plan predicted, using the same measure the gap was originally stated in.
Act; standardize the fix so it holds, or repeat the cycle if the check shows the gap isn’t closed yet.

The sequence doesn’t change based on which antipattern triggered it. A team fixing missing WIP limits and a team fixing ceremonial Participatory Budgeting run the identical four steps against two completely different standards, which is exactly what makes the method reusable instead of bespoke.

Pointing the A3 at Any Entry in This Catalog

Pointing a problem-solving A3 at a specific entry in this catalog starts with naming the standard being violated, a WIP limit, a time-boxed iteration, an insight-generation step in a retrospective, rather than describing the symptom in general terms. Once the standard is named, state the gap in measured terms: not “our funnel feels congested” but a specific count of epics sitting unresolved past a defined age threshold.

From there, the team runs the same four steps rather than improvising a bespoke fix per entry: plan against the measured gap, implement at the scope the plan defines, check the result against the same measure, and standardize or repeat. One disciplined method, pointed at thirty different gaps, is more learnable across a team than thirty different repair procedures memorized individually: a Scrum Master who has run the cycle once for a retrospective antipattern already knows how to run it for a funding antipattern, because the spine never changes, only the standard being checked against.

Summary

Every entry in this catalog is a solution that looks reasonable in isolation and fails only once a specific precondition underneath it is missing; value stream capacity, an active Epic Owner, incremental delivery, a genuine insight-generation step. Diagnosing by dimension, not by principle, is what makes thirty separate names usable rather than overwhelming.

Cluster by Symptom, Not by Principle

A reader who arrives at this catalog with one specific pain, a funnel that won’t stop growing, a retrospective that keeps producing the same three action items every iteration, a velocity chart leadership keeps citing in a funding conversation, doesn’t need to read ten principle pages to find the relevant entry; the matching dimension is one heading away. Laid out this way, the five clusters aren’t evenly weighted: Strategy and Investment Funding accounts for seven of the thirty entries, the largest single cluster, with Agile Portfolio Operations and Metrics and Goal-Setting tied at six apiece, Lean Governance at five, and Team Ceremony the smallest at three. Money and portfolio-flow mechanics generate more nameable, checkable failure conditions than any other operating layer in this catalog; retrospective failures are comparatively rare because Corry’s own taxonomy already covers that ground tightly with three names instead of the same ground scattering across a longer list.

That grouping also exposes something a principle-by-principle list hides: failures inside the same dimension compound each other. A portfolio running committee-based prioritization, a reintroduced Stage-Gate Process, and rigid guardrails simultaneously isn’t experiencing three unrelated problems: it’s experiencing one governance layer that accumulated friction from three directions at once, and fixing only one of the three leaves the other two still slowing every decision that passes through.

One Remediation Method Beats Thirty Improvised Fixes

The problem-solving A3, built on the same Plan-Do-Check-Act spine regardless of which entry triggered it, is what keeps this catalog from turning into thirty separate repair manuals. Naming the violated standard and stating the gap in measured terms works identically whether the standard is a WIP limit, a funding horizon, or a retrospective’s insight-generation step: the discipline transfers across dimensions even when the specific fact pattern doesn’t.

That order matters more than the vehicle itself: before opening an A3, name which of the five dimensions actually matches the pain in front of you, and check whether a specific standard has drifted, a WIP limit, a funding horizon, a retrospective’s insight-generation step, rather than starting from the symptom’s surface description (“the funnel feels congested,” “velocity looks flat”). Confirming the wrong dimension first is the fastest way to spend a full PDCA cycle solving a standard that was never actually violated. Once the dimension and the specific entry are both named, the four-step spine in the Escape Route section above is the fix; the ordering discipline belongs here, ahead of it.

agility at scale