SAFe is Not Safe: A Better Playbook

Introduction

Most people don't adopt SAFe because they wake up craving more process. They adopt it the same way they buy a new treadmill in January: it looks like discipline, it promises results, and it makes everyone feel like they are finally "doing the right thing." The slide decks get cleaner. The calendars fill with meaningful-sounding ceremonies. The dashboards light up with reassuring colors. For a while, it even feels like progress.

Then the real work starts.

A team is trying to ship something that matters. A real customer is stuck. A mission need is evolving faster than the plan. A production defect shows up at the worst possible moment. And suddenly, the question isn't whether the train is "on cadence." The question is whether anyone has the authority to make a decision today, whether engineers can change the code safely, whether the work can flow without waiting for a meeting, and whether learning is allowed to overwrite last quarter's commitments. This is the moment when the gap between "Agile theater" and modern software delivery becomes painfully obvious.

If you've lived through it, you know the pattern. The organization wanted agility. What it got was a sophisticated form of bureaucracy that uses Agile language. The intent was alignment. The outcome is often alignment around the wrong thing: outputs over outcomes, plans over evidence, predictability over adaptability, ceremony over engineering. The sprint reviews and PI events can become a substitute for customer feedback. The "commitment" becomes more important than the learning. And the cost is not just wasted time. It's degraded initiative, slower feedback loops, and teams that stop behaving like teams and start behaving like participants in a compliance system.

This post is written for the people who feel that friction in their bones: engineers who are tired of rearranging their work to satisfy process, product leaders who can't reconcile what users need with what the plan says, and executives who sense that "we're busy" is not the same as "we're delivering." It's also written for the well-intentioned SAFe adopters who were promised a scalable path to agility and are now quietly wondering why delivery still feels brittle, slow, and expensive.

Here's the blunt argument: SAFe is frequently not just "not Agile." In many environments, it is actively harmful. It provides a comforting illusion of control while incentivizing behavior that makes modern software delivery harder: centralized decision-making, fixed plans that resist learning, and a reliance on ceremonies that crowd out the technical discipline required for rapid, safe change. It can make an organization look coordinated while it accumulates waste in plain sight.

The good news is that there are alternatives that are both simpler and more effective, and they are not exotic. At the team level, the best results come from flow and engineering excellence: Kanban to manage work as a system and XP to ensure we can change code safely, continuously, and with confidence. At the portfolio level, the best results come from funding value streams, governing by outcomes, and using lightweight mechanisms—portfolio Kanban, WIP limits, OKRs, and evidence-based decisions—to align effort without crushing autonomy. And yes, if you're forced to participate in SAFe, there are pragmatic ways to minimize the damage while you build the capability to move beyond it.

If you've ever walked out of a planning event thinking, "We just spent two days negotiating a plan we already know won't survive contact with reality," keep reading. This is about trading theater for throughput, bureaucracy for learning, and process comfort for delivery competence. The kind that both business leaders and engineers can recognize when it shows up in the only place that matters: outcomes in the hands of real users.

From Waterfall to Agile

Before we talk about why SAFe misses the mark, it helps to remember what problem Agile was trying to solve in the first place, because Agile was not born as a preference for stand-ups. It was born as a reaction to failure.

For a long time, especially in large government and defense programs, "professional software development" meant something very specific: a linear lifecycle. In 1985, the Department of Defense published DOD-STD-2167, which set expectations for working with software development contractors. It explicitly required a development cycle with defined phases: Software Requirements Analysis, Preliminary Design, Detailed Design, Coding and Unit Testing, Integration, and Testing. In other words, the system assumed you could know the problem up front, design the solution up front, and then build it as a controlled execution exercise. That approach became the waterline for what "good process" looked like.

The logic was tidy. The outcomes often were not.

What's interesting is that even "waterfall" itself is often traced back to a paper that was not intended as a model to copy. In 1970, Winston W. Royce published "Managing the Development of Large Software Systems." It included a diagram that looks like the classic waterfall flow, and then, crucially, he immediately warned that this single-pass, sequential approach was risky and likely to fail for complex software. Royce advocated adding feedback loops, early validation, and iterative elements to reduce risk. Over time, however, the diagram became the icon, while the caution became a footnote. The industry adopted the picture as doctrine and ignored the warning that came with it.

Traditional waterfall approaches leaned hard into big design up front (BDUF) and cascading, consecutive phases. The plan would look beautiful. The documents would be thorough. And then reality would arrive ... late and expensive. Requirements would shift because users learned what they actually needed. Integration would reveal hidden coupling. Testing would surface defects that were baked in months earlier. And because feedback arrived at the end of the chain, the cost of change was punishing. The pattern wasn't just "inefficient." It created a predictable failure mode: a disproportionate number of software projects that were late, over budget, brittle, or never delivered the intended value.

Agile emerged as an attempt to fix that, and, in many ways, to professionalize the discipline around what high-performing teams were already learning the hard way: software is not a manufacturing line. It is a discovery-and-decision system operating under uncertainty. When you treat it like a requirements-to-code assembly line, you optimize for paper confidence and pay for it later in rework.

That is the context in which the Agile Manifesto was written. A small group of industry practitioners didn't set out to codify "the one right process." They wrote down the values and behaviors that consistently produced better results in messy reality. They captured it in a short statement that still reads like a direct rebuttal to waterfall instincts:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Manifesto for Agile Software Development

Those values weren't anti-process. They were anti-illusion: a refusal to confuse process compliance with delivery competence. And the Manifesto's principles made the intent even clearer. Teams win when they can welcome changing requirements, even late. They win when working software is the measure of progress. They win when they treat technical excellence and good design as continuous work, not something postponed until the end.

This is the stage-setting point: Agile was a mindset first. A method second. It was a shift from predictability-through-control to adaptability-through-feedback. It didn't eliminate planning. It changed what planning was for: planning became a tool for learning and coordination—not a mechanism for locking reality in place.

With that context, the critique of SAFe becomes much simpler. The question isn't "Does SAFe have Agile words?" It does. The question is whether SAFe tends to recreate the waterfall operating logic—centralized control, plan protection, ceremony as governance—under an Agile label. That's where we go next.

Why SAFe is Not Agile

If you want to understand why SAFe fails in practice, start with a scene most teams can recite from memory: day one of PI Planning. The room is full. The boards are covered. Everyone is "aligned." Engineers estimate work that depends on teams they rarely talk to, architecture decisions that haven't been validated, and assumptions that will be wrong by next week. By the end, there's a plan that feels authoritative because it's detailed. Commitments feel real because they're public. Leadership walks away relieved because uncertainty has been converted into a schedule.

That relief is the tell.

SAFe (Scaled Agile Framework) looks like the word "safe" with an extra "e." In a lot of organizations, that is the point. It creates order: a shared vocabulary, a shared calendar, and a shared set of artifacts that make uncertainty feel manageable. But feeling safe isn't the same thing as being agile. When the operating model optimizes for predictability and compliance over learning and adaptation, you get a system that performs agility instead of practicing it.

Then reality shows up.

A user need shifts. A dependency breaks. A security constraint arrives late. A production issue consumes the best people. The team learns something critical. The plan should change, but the system is optimized to protect the plan, not the learning. That is the core reason SAFe is not Agile: it preserves old management habits, locks organizations into hierarchy and control, and prioritizes predictability and compliance over experimentation and learning. In doing so, it conflicts with the Agile Manifesto's operating logic: empowered teams, rapid feedback, and adaptation to change.

SAFe gives the illusion of 'adopting agile' while allowing familiar management processes to remain intact.

Jeff Gothelf

A big part of the problem is the vocabulary trap. SAFe uses the right words—continuous learning, DevOps, customer centricity, innovation—but those terms often map to hierarchical, plan-driven processes in day-to-day execution. The result is "Agile in name, waterfall in execution." The organization gets the language of modern delivery without the behaviors that make it work.

The structural failure follows quickly: Program Increments become stage gates with better branding. SAFe borrows words like scrum, iteration, and backlog, but frequently deploys them in rigid, hierarchical ways. Program Increments (PIs) become long, plan-driven cycles that behave like mini-waterfalls, with success measured by hitting PI commitments rather than responding to change or delivering new insights. Once the PI commitment becomes the scoreboard, teams rationally optimize for the scoreboard: risk is managed by deferring hard problems, discovery gets squeezed because it threatens predictability, and work gets shaped to fit the plan instead of being shaped by evidence.

Next comes the bureaucracy. Agile thrives in small, empowered teams. SAFe often scales by layering process until teams are constrained. The role stack expands. Cadence becomes control. Feedback loops slow because teams wait for ceremonies and approvals instead of learning continuously from customers or mission users. Decision-making centralizes. Authority shifts upward, reducing trust and self-organization.

Big and agile don't go together… There's nothing quick and nimble about scaled agile.

Thomas Junghans

Once that machinery is in place, continuous discovery tends to be the first casualty. Not because anyone dislikes learning, but because the incentives and calendar quietly punish it. Predictable delivery becomes the goal. Discovery work becomes optional. "Design thinking" and "customer centricity" become icons rather than daily practice. Discovery and delivery get decoupled: learning is treated as separate from execution rather than integrated into the work.

SAFe ... gives the management a mandate to call themselves agile and keep doing what they have always done.

Steve Denning

At some point, the critique stops being just "engineering opinion" and becomes a credibility problem. The Agile Manifesto is explicit about what matters most: people and interactions, working software, collaboration, and responding to change over following a plan. SAFe can invert those priorities in practice, elevating process, predictability, and hierarchy over autonomy, feedback, and learning. That's why some of the strongest objections come from the originators of Agile themselves.

SAFe gives what may be sincere lip service to good Agile and Lean practice ... However, SAFe wraps those ideas in a package that is designed -- intentionally in my opinion -- to appeal to today's managers and executives who do not understand Agile, but who know they have a problem to which Agile may be the solution.

Ron Jeffries

Finally, even if someone argues "Fine, but SAFe still works," the evidence is sobering: large-scale studies comparing popular scaling approaches report that differences in team effectiveness are small and not practically significant. That implies the choice of scaling framework is not the lever organizations think it is. Effectiveness comes from culture, technical excellence, and leadership behaviors that support continuous learning and delivery—not from a branded framework.

Don't even think about using some abomination such as SAFe. It's neither "agile" nor "safe." The approach behind SAFe is not appropriate for projects in the Complex domain.

Andy Hunt

If you strip away the vocabulary and look at the operating behavior, the mismatch is straightforward:

SAFe advocates will often respond with some version of: "You're describing bad SAFe." That's fair in theory, but it avoids the practical issue: the incentives and gravity of SAFe make these failure modes common, not rare. Here are the most frequent counterarguments you will hear, and the underlying tension they don't resolve:

Don't take my word for it

If you want independent, practitioner-grade critique (not just opinion), start with ThoughtWorks' Technology Radar entry on SAFe. ThoughtWorks has repeatedly kept SAFe in "Hold (Proceed with caution)" and explains why: over-standardized, phase-gated processes; friction in operating models; silos; top-down control that generates waste; and reduced autonomy and experimentation. They explicitly recommend leaner, value-driven approaches and governance instead of treating SAFe as a shortcut to agility.

I don't think SAFe is evil, I can imagine some circumstances, with the right combination of people, where it would work. The trouble is that you can say that about anything, even waterfall sometimes works by accident, if you have people in-place that can navigate it. I think that SAFe is misguided.

Dave Farley

Next, read what the people who literally wrote the Agile Manifesto have said when asked about SAFe. SmHarter's curated collection aggregates comments part 1 and part 2 from multiple Manifesto signers and other senior practitioners. For example, Andy Hunt's assessment is direct: "SAFe is not an agile approach." This matches Ron Jeffries' similar sentiment where he wrote, "Bottom Line: SAFe isn't Safe."

You'll find similar through-lines from other signers:

• Jeff Sutherland (Scrum co-creator) argues that frameworks like SAFe may be a "starting place" for the uninitiated, but can codify dysfunction and cripple teams if treated as the model.
• Martin Fowler (ThoughtWorks) is publicly skeptical of SAFe's outcomes and incentive structure, reflecting the broader ThoughtWorks posture captured in the Radar entry. During a panel at the GOTO conference, Fowler stated, "SAFe stands for the Shitty Agile For Enterprises, as my friend calls it."

If you want broader critique and commentary from experienced practitioners, start here:

• SAFe Delusion
• Verwijs & Russo (2024), Empirical Software Engineering: Do Agile scaling approaches make a difference?

Team Alternatives to SAFe

Before we talk tools, we need to separate two things that organizations constantly confuse: mindset and methodology.

A mindset is a way of thinking—an attitude or belief system that shapes how you approach problems and opportunities. It's philosophical and cultural, not a checklist. When we say "Agile is a mindset," we mean you value adaptability, collaboration, and continuous improvement in the way you make decisions and the way you behave day to day. In that sense, mindset is your compass: it gives direction through values and principles. It answers the question: Why are we doing this, and how do we think about tradeoffs under uncertainty?

A methodology (or process/framework) is different. It's a structured way of doing things—practical and prescriptive. It gives you defined steps, practices, roles, and tools to apply. Scrum, for example, is a methodology: it's a framework that applies Agile principles through sprints, roles, and ceremonies. In that sense, methodology is your map: it gives routes, steps, and methods. It answers the question: What are we doing next, and how do we do it?

Maps are useful. But maps aren't wisdom. A map cannot tell you when the terrain has changed, when the route is blocked, or when the objective itself is wrong. That's the trap many organizations fall into with SAFe (and frankly with any branded framework): they try to "install Agile" by installing a process. They follow the steps mechanically. They add roles. They hold the events. They produce the artifacts. And because it looks like motion, it feels like progress.

But if you only follow a process mechanically—without the mindset—you risk missing the true intent. You can do every ceremony and still fail to learn. You can "plan" perfectly and still ship the wrong thing. You can measure predictability and still be incapable of adapting when reality changes.

That distinction matters because the team-level alternative to SAFe is not "replace one framework with another." It's a different bet entirely: stop investing in ceremony and start investing in capability. Modern teams move fast for one reason: they can learn quickly and change software safely. The rest is decoration.

And here's the key point that unlocks the rest of this section: you can adopt the Agile mindset without using Scrum, SAFe, or Kanban. Those are methods. The mindset is bigger than any of them. The goal isn't to be compliant with a framework. The goal is to build teams that can continuously deliver working software, learn from users, and adapt without drama.

The backbone of that capability is a small set of practices that reinforce each other:

If you want a single mental model for this section, it is this:

• UCD explores the problem
• Lean helps you build the right thing
• XP (Agile) helps you build the thing right
• DevOps helps you deliver with speed and safety
• Mission-aligned teams & flow architecture create shared understanding, align to value, and keep work flowing to outcomes

This is the team alternative to SAFe: not a bigger planning event, not more roles, not a more elaborate calendar. A system that makes learning fast, change safe, and delivery continuous.

What follows is the story of how those pieces fit together.

Lean Product Management

Lean makes more sense when you remember what it replaced.

Early scientific management tried to maximize efficiency through process, rules, and control. Work was standardized, broken into small repeatable tasks, and reassembled into tightly managed procedures. That approach can improve consistency in predictable environments, but it breaks down in modern software development where the work is complex, dynamic, and full of unknowns. When uncertainty is high, "control through planning" becomes a trap: it rewards plan adherence over learning, outputs over outcomes, and activity over value.

Lean product management is the correction. It assumes you cannot think your way to certainty. You have to learn your way forward. Most delivery waste isn't "engineers are slow." It's engineers being precise about the wrong target. Lean exists to prevent that. It shifts the focus from outputs (features delivered, tickets closed, plans met) to outcomes (mission impact, user value, measurable improvement). It treats roadmaps as intent, not contracts, and it insists on a simple discipline: build, measure, learn—continuously.

In practice, Lean changes who owns value and how decisions get made. Instead of a chain of handoffs, Lean favors empowered product trios—product management, design, and engineering—jointly accountable for outcomes. Not "delivery to spec." Not "meeting the plan." Outcomes. That trio is how you keep discovery connected to delivery, so you don't end up with beautiful backlogs and disappointing results.

Lean is also unapologetically experimental. It prefers experiments over certainty: test assumptions before committing real money and time. If you can't validate the riskiest assumptions early—about users, workflows, data, constraints, adoption, security, integration—then you are not managing risk. You are deferring it. Lean replaces the comfort of detailed plans with the safety of evidence. The learning mindset is the point: adapt based on what you observe, not what you promised two months ago.

And none of that matters unless it stays anchored on customer and mission. Lean isn't "build whatever the business wants faster." It is: prioritize work tied to real user needs and mission value, then validate that value through feedback and measurement. When Lean is working, the organization stops arguing about priorities in abstract terms. It talks about outcomes, evidence, and tradeoffs.

If you want a practical way to remember Lean product management, it's this: a learning system for delivering mission value—not a planning system for delivering outputs.

User-Centered Design

If Lean helps you pick the right objective, User-Centered Design helps you understand the battlefield. It is not a "design phase" you schedule after requirements. It's a continuous discipline of reducing uncertainty: observe the user's world, test assumptions early, and bring evidence back to the team while changes are still cheap.

Here's why UCD matters in the SAFe conversation: SAFe-style operating models tend to reward predictability artifacts—plans, backlogs, commitments, and calendars. UCD is disruptive because it introduces new information at the exact moment the system wants the plan to stop moving. But that tension is the point. UCD is how you earn predictability in complex work—not by freezing assumptions, but by replacing guesswork with evidence early enough to matter.

A good UCD rhythm feels less like "design handoff" and more like a handshake between discovery and delivery. The team keeps a thin pipeline of validated work—small slices that can be built, tested, and learned from—so learning and delivery stay coupled. That coupling is the difference between "we shipped what we planned" and "we shipped what actually works."

UCD is also one of the most abused terms in modern tech culture, usually because it gets blurred with Design Thinking. They are related, but they are not the same thing. Design Thinking is a mindset for exploring complex problems in a world full of uncertainty—often emphasizing human needs, meaning, and experience. It's comfortable with ambiguity. It uses intuitive and abductive reasoning to explore what is and imagine what could be. UCD is more operational: it is what you do when you decide that "understanding users" isn't a workshop, it's a delivery discipline.

Donald Norman captured Design Thinking in practical terms as a set of moves: determine the real problem, search for solutions, consider many options, and converge on a proposal. That maps cleanly to the familiar diverge/converge loop: explore broadly, then narrow with intent. UCD takes that mindset and makes it repeatable in the life of a product team through an iterative loop—discover → define → prototype → test → refine—and it does it with real users, in real contexts, against real constraints.

But here's the part that matters most, and the part organizations get wrong: Design Thinking is not a process. It's a set of abilities. It's about dealing with ambiguity, empathetic learning, synthesis, and experimentation. Processes and tools are guardrails that help us practice those abilities, but it's by doing design that we become better designers—not by following a five-step diagram.

This is also why Design Thinking should never be treated as "the designers' job." It's an inclusive, collaborative activity that everyone participates in. In mature teams, designers often act as facilitators—creating the conditions for better thinking, better questions, and faster learning across the whole product trio and stakeholder community. If you want a short provocation in this direction, see: "Let's stop talking about THE design process".

And yes—Design Thinking can become theater. When it gets reduced to a branded workshop, a pile of stickies, and a required set of artifacts, it becomes the same kind of performance SAFe creates—only with different props. If you want a sharp antidote to that flavor of theater, the intentionally profane designfuckingthinking.tumblr.com is worth visiting. You don't have to agree with every take to recognize the underlying critique: a process can become a performance if it is disconnected from outcomes and reality.

So if UCD and Design Thinking are not "a process," what are they? They are a portfolio of abilities that teams cultivate over time. Here is a practical map that you can use to assess and build those abilities.

When UCD is functioning as a delivery advantage, it looks like this:

• Start with the problem, not the solution: frame challenges through the user's perspective and mission context.
• Prototype and test early with real users: validate assumptions before time and politics lock in the wrong path.
• Keep discovery and delivery coupled: continuous discovery + continuous delivery, not a "discovery phase" followed by "execution."
• Collaborate cross-functionally: diverse perspectives reduce blind spots and accelerate learning.
• Stay mission-aligned: solve real operator and analyst problems—not just produce impressive demos.

A narrative way to remember UCD is simple: it is the difference between arguing about what users want and watching them try to use what you built.

In a healthy organization, UCD doesn't slow delivery. It prevents waste. It makes teams faster by preventing them from building the wrong thing with high efficiency. And it creates something no amount of ceremony can manufacture: shared understanding grounded in reality.

eXtreme Programming (XP)

This is the part that separates performance from theater: XP. A lot of teams adopt Agile rituals and wonder why delivery still feels brittle. It's because they adopted a scheduling system, not an engineering system.

XP is Agile's technical foundation. It treats quality as a design constraint, not a phase. It assumes you will need to change your mind (because reality always wins), so it builds the capability to change safely: automated tests, refactoring discipline, continuous integration, and shared ownership.

If you want a single sentence: XP makes change cheap.

That phrase is easy to nod at until you've lived the alternative. In brittle systems, every change is a negotiation with fear. People avoid touching "that area of the code." Releases become events. A simple fix drags a shadow of regression risk behind it. Teams build elaborate planning and coordination rituals because they cannot trust the software to absorb change. XP flips that equation. Instead of trying to plan uncertainty away, XP reduces the cost of learning by making software safe to modify.

Here's what XP looks like when it's working. A production bug appears and the team does not panic. They reproduce it quickly. They write a test that proves the failure. They fix the code. The pipeline runs. The fix ships. The system stays stable. Nobody schedules an emergency regression week. That is agility—not because the team is heroic, but because the system makes the right behavior easy.

The image above captures why XP works: it aligns planning cadences with engineering feedback loops. Long-range plans live at the outside of the circle (months). But the ability to adapt is built in the inner rings (minutes, hours, 24 hours): pairing, unit tests, CI, and acceptance checks. When those inner loops are healthy, planning becomes lighter because the software itself provides trustworthy feedback.

XP also changes the team's relationship with design. It pushes for simplicity: build only what is needed now, keep the design malleable, avoid speculative complexity, and refactor continuously. It insists on a sustainable pace because tired teams create brittle systems, and brittle systems force tired teams into heroics. It prefers collective code ownership because knowledge silos create fragility and risk; shared responsibility creates resilience.

Here is the practical consequence: XP enables frequent, safe change. Teams can adapt quickly with confidence because they have built the engineering capability to do so.

XP isn't just a set of engineering mechanics. It's grounded in a small set of values that show up as day-to-day behavior. These values matter because they explain why XP works in real organizations: they create teams that communicate early, seek feedback relentlessly, and keep the codebase simple enough to change.

XP and Scrum are often talked about as if they're interchangeable "Agile methods." They aren't. XP is primarily an engineering discipline—it tells you how to build software that can safely change. Scrum is primarily a work management framework—it tells you how to structure planning, roles, and ceremonies. Scrum can work well when it is paired with XP-level engineering practices. But in the real world, Scrum frequently degrades into process theater when technical excellence is treated as optional.

This is the core issue: XP prioritizes engineering discipline and continuous quality, while Scrum is mostly a coordination wrapper. If the organization already has strong engineering habits, Scrum can be a lightweight way to organize planning. But if engineering discipline is weak—or leadership is hungry for predictability artifacts—Scrum can easily become a mechanism that standardizes ceremony while the codebase quietly becomes harder to change. That's why, for most organizations trying to escape SAFe-style theater, the safer bet is to build an engineering system (XP) and then choose the lightest coordination system that supports flow—often Kanban.

The heart of Agile is building great software solutions that adapt gracefully to changing needs. Agile begins with a problem—not a requirement—and delivers an elegant solution. The Agile mindset accepts that the right solution today might not be the right solution tomorrow. XP is how teams make that truth survivable. It makes change safe, frequent, and boring in the best possible way.

Mission-Aligned Teams and Flow Architecture

Many organizations assume their delivery problems come from "scale." More often, the real culprit is dependency debt: too many handoffs, unclear ownership, and architecture that forces coordination for every change. You can add roles, planning rituals, and more "alignment" meetings, but none of that pays down dependency debt. It just turns coordination into a permanent tax.

Mission-aligned teams exist to break that pattern. They are designed around outcomes and value, not around temporary projects. They own a slice of capability end-to-end and have clear decision rights within guardrails. This is not a soft cultural preference. It is a hard constraint for speed. If every change requires cross-team negotiation, your process will never be agile enough to compensate.

This is also where the idea of a balanced product team becomes non-negotiable. Fast teams don't "hand off requirements" to engineering and hope for the best. They operate as an integrated unit that can make tradeoffs in real time. A useful shorthand is the product trio:

• Product owns viability: which outcomes matter, what bets are worth placing, and how success will be measured.
• Design owns desirability: how work actually happens, what users will recognize as helpful, and what fits the operational context.
• Engineering owns feasibility: how to build and operate change safely, and how to keep the system malleable.

The trio is not a committee. It's a decision engine. When it's healthy, decisions get made at the point of work without constant escalations, and without converting uncertainty into bureaucracy.

Flow architecture is the technical mirror of mission-aligned teams. It reduces friction by clarifying boundaries, stabilizing interfaces, and investing in platforms that remove repeated toil. Put differently: it makes the easy path the safe path. When architecture forces constant coordination, teams become integration clerks. When architecture supports clear seams, teams can learn, ship, and adapt.

A simple before/after memory aid:

The table is the symptom. The next question is what to do about it, because once you admit you're paying a coordination tax, you need a design approach that addresses the root causes, not just the schedule. This is where flow stops being a slogan and becomes an architecture problem. A useful frame comes from Architecture for Flow: flow is not something you "process" your way into. It's something you design across three layers: strategy (what matters and what should be commodity), architecture (where boundaries live and where change is contained), and teams (how work is owned and how interactions happen).

Start with strategy, because most organizations accidentally treat everything as equally strategic. When that happens, everything becomes "custom," everything becomes tightly coupled, and teams spend their time coordinating instead of delivering. A technique like Wardley Mapping helps here because it forces you to draw the chain from user need to enabling components, then asks a hard question: which parts are true differentiators and which parts are commodities you should standardize or buy? That clarity is not academic. It prevents architecture sprawl and investment dilution. A simple test: if your roadmap treats everything as equally strategic, your architecture will treat everything as equally coupled—and your teams will feel it.

Then move from strategy into architecture, because seeing the terrain is not enough—you have to cut the system where change actually happens. This is where Domain-Driven Design (DDD) earns its keep. DDD is not a microservices mandate; it's a boundary discipline. It helps you analyze the domain, define seams (bounded contexts), and keep core business logic decoupled from volatile edges like integrations, external policy churn, and UI shifts. The payoff is practical: fewer surprises, fewer cross-team negotiations per change, and more autonomy with alignment because changes stay local instead of rippling through the enterprise.

Of course, boundaries on paper don't reduce coordination by themselves. They only pay off if the organization assigns clear ownership and uses interaction patterns that keep collaboration purposeful instead of constant. That's the missing link between "better architecture" and "better flow": you have to make the team system match the architecture.

Once you have boundaries, Team Topologies gives you a sane way to design teams and interactions so cognitive load stays manageable and coordination stays intentional.

At a high level, there are four team types:

• Stream-aligned teams: the default. Own a flow of work tied to a user/mission outcome.
• Platform teams: build internal products that reduce friction (environments, CI/CD, paved roads, observability).
• Enabling teams: temporary capability builders who help stream teams adopt new practices and then step back.
• Complicated-subsystem teams: contain deep specialist complexity so it doesn't leak everywhere.

And three interaction modes:

• Collaboration for short, intense joint discovery.
• X-as-a-Service to reduce coordination to a stable interface.
• Facilitating to build capability (coaching, pairing, enablement).

The point is not to rename teams. The point is to reduce bottlenecks and improve flow by design. But even with better boundaries and better team interactions, you still need a day-to-day operating mechanism that keeps work moving in reality, not on slides. That's where Kanban fits—because Kanban is fundamentally a flow discipline. Mission-aligned teams need a way to manage work that reflects what actually happens: unplanned work arrives, priorities shift, and dependencies surface. Kanban provides a lightweight system for making that visible and improving it over time without pretending you can plan uncertainty away.

Kanban in this context is not "a board." It's a set of controls for flow:

If you want four metrics that reduce theater instead of increasing it, use:

• Lead time (request → value delivered)
• Cycle time (active work duration)
• Throughput (items completed per time)
• WIP (items in flight, and therefore at risk)

Kanban is also honest about operational reality. If you are in an environment with interrupts—production issues, security findings, urgent user needs—Kanban doesn't treat that as failure. It treats it as part of the system. You make it explicit: reserve capacity, use swimlanes, and track the cost of interruption instead of hiding it.

At that point, the conversation stops being "Which framework do we run?" and becomes "Do our choices reinforce flow end-to-end?" Speed without chaos requires the pieces to fit together—strategy, architecture, teams, and execution reinforcing one another instead of fighting each other. That's why it helps to think in terms of a coherent flow stack:

• Balanced product teams (product trio) to make real tradeoffs at the point of work.
• Wardley Mapping to separate commodities from differentiators and anticipate change.
• Value stream mapping to reveal queues, delays, and handoff tax.
• DDD boundaries to contain change and reduce coordination per decision.
• Team Topologies to align team structures and interactions to the architecture.
• Kanban to manage work as a flow system.
• XP to keep the system continuously shippable and safe to change.

This is how you scale without scaling theater. You don't scale ceremonies. You scale clarity (outcomes and ownership), capability (engineering and product decision-making), and structure (boundaries and platforms) so that learning turns into shipped value with minimal friction.

The end state is simple: small teams with clear outcomes, autonomy within guardrails, and an architecture that makes change routine without turning coordination into a full-time job.

DevOps

DevOps is where all of this becomes real. Without DevOps, an organization can talk about agility and still operate like it's 2005: manual releases, fragile environments, late security surprises, and "stabilization" phases that exist because nobody trusts the system.

DevOps turns delivery into a repeatable mechanism. Automated pipelines make change boring. Embedded security checks prevent "surprise findings" at the end. Observability makes reality visible in production so teams can learn quickly and recover fast. It shortens the distance between "we changed something" and "we know what happened." It also changes the emotional tone of engineering work: shipping stops being a cliff dive and becomes routine.

A useful way to remember DevOps is that it collapses time: between code and customer, between incident and recovery, between hypothesis and evidence. When DevOps is working, the outcomes show up in how the organization feels day to day:

At a practical level, DevOps is the path to production as an enabler of agility. CI/CD pipelines, automation, and observability are not "engineering hygiene"; they are the mechanism that allows ideas to move quickly from code to the user, with guardrails that keep reliability and compliance intact. And once you start fielding AI-enabled capabilities, DevOps becomes the foundation for MLOps/AI Ops in mission environments: if you cannot reliably build, test, deploy, observe, and roll back software, you will not be able to scale and sustain models, data pipelines, and retraining loops either.

DevOps is often summarized as three reinforcing feedback loops—flow, feedback, and continuous learning. In plain terms: move work from commit to customer smoothly, detect problems quickly, and improve the system continuously.

If Agile is the intent, DevOps is the delivery engine. It is what makes the system trustworthy enough to move quickly—especially in environments where reliability, auditability, and security are not optional.

Portfolio Level

SAFe scales bureaucracy. Portfolios should scale outcomes.

At the portfolio level, the job is not to create a bigger plan. The job is to create the conditions where teams can reliably discover, deliver, and adapt without needing permission for every decision. That means aligning funding to value streams, empowering product lines with clear decision rights, and guiding with lightweight principles: Lean product thinking, continuous discovery, outcome-based governance, and flow-based coordination.

This is where the compass versus map distinction matters most. A portfolio needs a compass because the terrain keeps moving. The compass is made of durable principles and intent: mission outcomes, user needs, strategic constraints, and the operating rules that keep teams aligned while they move fast. The map is whatever framework you are currently running. Maps are useful, but they go stale quickly in complex environments. Portfolios that confuse maps for compasses end up managing the plan instead of managing results.

Team-level agility is necessary, but it is not sufficient. You can have strong engineering practices and still lose months to budget friction, approval latency, and coordination debt created above the team. This is the portfolio trap: leadership asks teams to be agile, then funds and governs them like a factory. Moving from teams to portfolio is a shift in what you optimize. At the team level, you optimize learning speed and safe change. At the portfolio level, you optimize the system that surrounds teams: how money moves, how priorities change, how risk is handled, and how cross-team dependencies are coordinated. If those mechanisms reward predictability over learning, the portfolio will pull teams back into theater no matter how good their practices are.

So the portfolio alternative to SAFe is not another heavyweight process. It is a small set of anchors that keep many teams moving in the same direction while preserving autonomy:

• North Stars and outcomes: define what "better" means in the real world and measure it.
• Value streams and product lines: organize around enduring capabilities, not temporary projects.
• Funding aligned to value: fund persistent teams and outcomes, not annual batches of scoped deliverables.
• Guardrails over gatekeeping: provide constraints (security, interoperability, compliance, architecture principles) without turning them into choke points.
• Flow-based coordination: manage dependencies as a system constraint, not a scheduling exercise.

If the team-level alternative is "stop investing in ceremony and start investing in capability," the portfolio-level equivalent is "stop investing in centralized predictability and start investing in decentralized learning guided by a shared compass." The practical shifts look like this:

Portfolio Principles and Governance

If team agility is about execution, portfolio agility is about environment. Teams cannot out-practice a portfolio that funds projects, rewards plan conformance, and treats governance as a series of gates. The portfolio alternative to SAFe starts with principles that are simple to say and difficult to operationalize. That is the point. Principles are the compass. They force tradeoffs when the map breaks.

Here are the portfolio principles that actually scale outcomes:

• Fund value, not projects. Projects end. Value streams endure. If funding is tied to temporary scopes and PI commitments, the organization optimizes for possessing a plan rather than improving outcomes. When funding is tied to product lines and value streams, teams can learn in public and re-balance based on evidence.
• Align on outcomes, not outputs. Outputs are what you build. Outcomes are what changes in the real world. Portfolios that govern outputs get feature factories. Portfolios that govern outcomes get decision discipline and learning velocity.
• Empower autonomy with guardrails, not bureaucracy. Autonomy without constraints becomes chaos. Constraints without autonomy becomes paralysis. The portfolio job is to define non-negotiables (security, compliance, interoperability, architectural principles, data standards) and implement them as guardrails that run continuously, not as gates that show up late.
• Continuously sense and respond. The portfolio is a control system. It should steer based on evidence: outcome movement, flow metrics, risk signals, operational feedback, and user learning. When sensing is episodic and steering happens quarterly, you do not have agility. You have a calendar.

Principles provide the compass. Governance provides the map. Without principles, governance becomes bureaucratic drift. Without governance, principles remain inspirational posters.

A useful way to make this real is to define a simple governance stack. Not more bureaucracy. A clear division of responsibility so governance improves flow instead of interrupting it.

This stack matters because teams optimize locally. They should. That is what autonomy is for. The portfolio's job is not to micromanage teams. It is to ensure contextual consistency: shared direction, shared constraints, and a coherent investment thesis so local optimization adds up to enterprise outcomes rather than accidental divergence.

This model also helps close the credibility gap between agile teams and executives. Teams want room to learn and ship. Executives want confidence that investments connect to mission value and risk is being managed. When the portfolio governs with outcomes, guardrails, and evidence, it creates that confidence without turning execution into theater.

Agile doesn't scale. It thrives in an environment. Scaling means creating that environment at the portfolio level.

Dan North

If you only take one point from this section, take this one: portfolio governance should feel like instruments and guardrails, not gates and approvals. When governance is designed as an environment, teams spend their time delivering value instead of navigating bureaucracy.

Funding and Flow

SAFe treats portfolios like a project factory. Lean portfolios treat them like an investment portfolio.

That difference sounds subtle until you see what it changes. A project factory funds plans, locks scope, and measures success by throughput of deliverables. An investment portfolio funds outcomes, expects uncertainty, and measures success by value delivered and learning gained. In other words, the portfolio stops asking, "Did we execute the plan?" and starts asking, "Did we improve the mission and what did we learn that changes our next bet?"

The first shift is funding. Replace project-based budgets with value-stream funding tied to durable product lines. Projects end just as teams finally understand the problem space. Product lines persist. When funding follows product lines, you get stable ownership, compounding domain knowledge, and the ability to reallocate based on evidence instead of re-baselining a contract every quarter.

Portfolio funding also needs balance. Mature organizations manage investment across three horizons:

This is where portfolios often lie to themselves. They say they want innovation, but they starve discovery and improvement. The result is predictable: the system stops learning, quality decays, and "transform" becomes a series of forced marches followed by a stabilization phase.

A lean portfolio keeps non-zero allocation for the work that preserves adaptation. Discovery and Kaizen are not optional side quests. They are how the portfolio prevents waste and keeps the delivery system healthy.

The second shift is flow. Portfolios should manage demand the same way high-performing teams do: make work visible, limit work in progress, and make tradeoffs explicit. Portfolio Kanban is the simplest tool for that job. It provides a clear picture of what is in flight, what is waiting, and what is stuck. More importantly, it forces the portfolio to confront the physics of delivery: starting more work does not create more output. It creates more delay.

Classes of service make portfolio tradeoffs honest. Not all work is the same, and pretending it is leads to chronic overload and priority whiplash. A useful set looks like this:

A portfolio that allocates zero to Discovery and Kaizen is declaring, whether it admits it or not, that it expects no uncertainty and no improvement. That is not strategy. That is denial.

WIP limits and evidence-based decisions are what keep this system adaptive. Limit the number of initiatives in flight. Make bets small. Slice work so learning arrives early. Then govern the portfolio like an investment portfolio: scale, iterate, or kill based on evidence. This is how you avoid the most common portfolio failure mode: a bloated backlog that never gets smaller, where everything is "priority" and nothing is actually finished.

The goal is not to be harsh. The goal is to be honest. If the portfolio cannot say no, it cannot move. If it cannot stop work that is not paying off, it cannot fund work that will.

Lean funding plus flow-based control does something SAFe struggles to do at scale. It creates a portfolio that can steer continuously, without turning every course correction into a new planning season.

Objectives and Metrics

PI objectives and feature counts create the illusion of control. They give you a neat scoreboard for activity, but they rarely tell you whether the mission is getting better. If you want portfolio agility, you have to stop managing output and start managing outcomes and learning.

The portfolio alternative is straightforward: replace PI objectives with Objectives and Key Results (OKRs) cascaded across product lines. Not cascaded as a compliance exercise, but as an alignment mechanism. The portfolio sets intent. Product lines translate intent into outcome bets. Teams translate bets into experiments, thin slices, and delivery.

This is where a North Star Metric matters. A North Star is not a vanity Key Performance Indicator (KPI) and not a quarterly target. It is a single guiding measure of long-term value that helps the portfolio answer one question consistently: are we building something that matters, and is it compounding over time? When the North Star is clear, OKRs become navigation, not negotiation.

A good portfolio metric system has two jobs. First, measure whether you are improving customer and mission value. Second, measure whether the delivery system is healthy enough to adapt. If you only measure the first, you can miss the fact that you are burning out the engine. If you only measure the second, you can ship beautifully engineered irrelevance.

A simple way to keep this balanced is to monitor portfolio health across three categories:

Delivery health metrics deserve special treatment, because they are your early warning system. You do not use them to punish teams. You use them to see whether the organization is still capable of learning quickly through software.

DORA metrics are a concise set that most leaders can understand and that correlate strongly with delivery capability:

When you run OKRs plus delivery health together, the governance conversation changes. Instead of asking, "Did you hit the plan?" leaders ask better questions:

• What outcome moved, and why do we believe it moved
• What did we learn that changes our next bet
• What is blocking flow, and what constraint should we remove next
• Is delivery health improving or degrading, and what investment is required to keep change safe

That last question is the real governance test. Portfolio agility is not hitting a schedule. It is demonstrating that learning drives decisions and that the system can change course without collapsing.

Collaboration and the Portfolio Playbook

SAFe assumes coordination is the primary scaling problem, so it responds with more coordination. More syncs. More ceremonies. More calendars. The result is predictable: the organization gets better at meetings and worse at flow.

Lean portfolios take the opposite approach. They treat coordination as a cost to be minimized, not a virtue to be maximized. The portfolio scales by providing structure and guardrails, then enabling teams to move with independence. Collaboration still matters. It is just designed to be lightweight, intentional, and triggered by real dependencies rather than by ritual.

Start with a simple rule: organize for independence first. If teams cannot deliver without constant negotiation, no meeting cadence will save you. Dependency debt will simply express itself as waiting, rework, and blame. The portfolio's collaboration strategy should therefore begin with team design.

A practical way to do that is to use Team Topologies (discussed earlier) as your collaboration grammar:

This structure does not eliminate collaboration. It makes collaboration explicit and purposeful.

When dependencies do exist, lean portfolios use mechanisms that maximize clarity while minimizing coordination load. The portfolio does not forbid face-to-face alignment. It just stops using it as the default.

This model also supports continuous discovery and delivery at scale. Portfolios cannot expect teams to "just ship" if discovery is treated as a separate phase or a special event. The portfolio has to make space for it and create a shared rhythm.

A useful mental model is the Double Diamond expanded across the portfolio. Discovery and delivery are not handoffs between functions. They are parallel loops that stay connected through evidence. Teams move from exploring the problem to delivering thin slices, then back again as reality updates the understanding.

One way to operationalize this is delivery mapping as a portfolio habit:

At this point the portfolio playbook becomes clear. It is not a checklist of ceremonies. It is a set of principles and operating mechanisms that create an environment where teams can deliver continuously.

Portfolio playbook, in one place:

The pattern is consistent: principles provide the compass, and the portfolio provides the environment. Teams deliver the value. The portfolio does not "run Agile" for them. It removes friction, sets intent, and makes it safe to learn in public.

Portfolio Agility

Portfolio agility is the final test, because it answers the question executives and engineers both care about: can we change course without collapsing the organization? If SAFe is the promise of control through scale, portfolio agility is the counter-claim: scale does not come from more choreography. It comes from creating an environment where many teams can sense and respond without waiting for permission.

Teams do agile; portfolios create the water they swim in.
That is the job at the portfolio level: shape the conditions that make good team practices compound instead of stall.

Here are the key takeaways, stated plainly and without ceremony:

• Principles scale. Portfolios provide the environment.
• Fund value streams, not projects.
• Align on outcomes with OKRs, KPIs, and a single North Star Metric that keeps the organization honest about long-term value.
• Manage flow with Portfolio Kanban and explicit WIP limits.
• Balance the portfolio across Initiatives, Discovery, and Kaizen so learning and improvement never get squeezed to zero.
• Guardrails over gates for governance and compliance, because constraints can be automated and made repeatable.
• Lightweight collaboration mechanisms (Team Topologies, API contracts, async RFCs) instead of standing meetings as a scaling strategy.
• Evidence-based governance: start small, then scale or kill bets based on what you learn.
• Metrics should reveal adaptability and outcomes, not activity.

If you want a portfolio-level "operating stance" you can remember in a hallway conversation, use this set of highlights:

• Setup: "Teams do agile; portfolios create the water they swim in."
• Funding: "We fund options, not certainties; we scale evidence."
• Kanban: "First-class work is Initiatives, Discovery, and Kaizen."
• OKRs/KPIs: "Replace commitment theater with outcome clarity."
• Cadence: "Guardrails ship faster than gates."
• Metrics: "Show adaptability, not activity."
• Playbook: "Principles, not prescription."

If you can do those things consistently, you get the outcome SAFe often promises but rarely delivers: a portfolio that can pivot without panic, invest without illusion, and scale learning faster than it scales bureaucracy.

Conclusion

Agility is not a framework — it's how organizations sense and respond.

Jeff Gothelf

If this feels like a lot, that is the point. Under pressure, most organizations reach for maps: frameworks, checklists, certifications, and consulting playbooks that promise, "Just follow this and you'll be Agile." That impulse is understandable. It is also how we end up scaling ceremony instead of capability.

We have seen this movie before. Waterfall became "the way" partly because a nuanced paper got misread as a prescription, and then institutionalized into standards and contracting culture. Royce presented a linear model as a warning and then spent the rest of the paper explaining why it was risky and what to do instead. DoD later codified a six-phase "software development cycle" as a contractor requirement. Once the map becomes policy, teams optimize for compliance, not outcomes.

The alternative is not "no process." It is compass first. Values and intent define direction. Practices build capability. Governance sets guardrails. Then you choose only the minimum process that helps people coordinate. That is why this post kept returning to the same idea: portfolios need a compass, teams need capability, and the connective tissue is flow.

If you want the practical shortcut, it is not a two-day certification. It is immersive learning. The best pattern I have seen looks like apprenticeship: embed your people with teams that already do the work well, long enough that the habits become muscle memory. Early Kessel Run did this by working alongside experienced commercial practitioners, then bringing those patterns back into their own context. That is training. A slide deck and a badge are not.

None of this is separable from culture. Culture is the substrate that decides whether principles survive contact with incentives, contracts, and "urgent priorities." If you want my longer take, I wrote about Organizational Culture on my blog two years ago.

I am willing to give SAFe the benefit of the doubt on intent. It borrows much of the same language as Agile and Lean, and in theory it tries to help large organizations coordinate. In practice, my experience has been that it too often becomes a feature factory with better branding. Even Thoughtworks has cautioned teams about SAFe in its Technology Radar. Your mileage may vary. But if your implementation trends toward heavier roles, more gatekeeping, and bigger planning cycles, you are not scaling agility. You are scaling bureaucracy.

The good news is that the broader environment is starting to reward the alternative. Recent Department of Defense guidance has emphasized modern software acquisition approaches and speed to capability, pushing organizations toward approaches that look a lot more like empowered product lines, continuous delivery, and evidence-driven iteration than annual "commitment theater." That is not a guarantee of success, but it is air cover for changing how Program Executive Offices (PEOs) and delivery organizations structure work.

So if you take one thing from this series, take this: stop trying to buy agility. Start building it. Start small. Pick one mission outcome that matters. Fund an enduring team against that outcome. Insist on XP-grade engineering, real UCD, and DevOps discipline. Measure what changes for users. Kill bets that are not working. Scale the ones that are. Repeat.

See the associated LinkedIn post.