2026-02-27 · standard-panel · Facilitated by Ren Ito
Why should I use SAFe in my organization?
The question on the table is: “Why should I use SAFe in my organization?” I want to note something about how this question is framed. It’s asking for the case, not against it. We have five people in this room, and I suspect most of you have strong priors. So before we begin — the question is sincere. Someone is asking this. They have a real organization, real coordination problems, and they’ve heard SAFe might help. Let’s take that seriously before we take it apart. Nora, you map landscapes. What does this landscape look like?
The first problem is that people say “adopt SAFe” as if it’s one thing. It’s not. It’s at least twelve things at four different maturity stages. Daily standups and sprint reviews — those are commodity practices. Every agile team does some version of that whether they call it SAFe or not. PI Planning — that’s a product. It’s a specific, packaged ceremony with a known structure. You can evaluate it. Portfolio alignment, strategic themes, lean budgeting — those are still custom in most organizations. They’re evolving, contested, and nobody’s standardized them. So the first answer to “why should I use SAFe” is: you need to decompose the question. You’re not adopting a framework. You’re adopting a bundle of components sitting at wildly different points on the evolution curve. The question is which components, for which problems, at which maturity.
I want to start somewhere else. Who bears the cost when SAFe fails? Not Scaled Agile, Inc. They’ve already been paid — for the training, the certification, the consulting. The certification ecosystem is beautiful if you’re selling it. You certify SAFe Program Consultants, they certify Release Train Engineers, the whole thing is a revenue flywheel. But it has no skin in the game for the buyer. If your SAFe implementation collapses in eighteen months, the certifying body doesn’t refund. The consultants have moved on. The people who bear the cost are the teams living inside the framework. So before “why should I use SAFe,” ask: who profits from my adoption, and do they share in my downside?
I want to back up further than either of you. Before you decompose SAFe’s components and before you ask who profits — what domain is your problem in? SAFe is a complicated-domain solution. It assumes your coordination challenge can be analyzed, decomposed into parts, and solved through best practice. Sense-analyze-respond. That works if your problem is genuinely complicated — many moving parts, but the relationship between cause and effect is knowable in advance. Most software delivery isn’t in that domain. It’s complex. The relationship between cause and effect is only visible retrospectively. You ship something, you learn what happens, you adjust. In a complex domain, the right move is probe-sense-respond — small experiments, fast feedback, emergent practice. SAFe’s entire architecture assumes you can plan a Program Increment and commit to it. That’s a complicated-domain move imposed on a complex-domain problem.
And even if your problem were complicated — even if Rhys’s domain classification said SAFe is structurally appropriate — there’s a prior question. What are the enabling conditions? SAFe is a mechanism. A set of roles, ceremonies, artifacts. But mechanisms don’t produce outcomes on their own. They require conditions. Does the executive team actually understand agile principles, or are they buying SAFe because a consulting firm told them it would “scale agile”? Are the individual teams already functional? Because SAFe coordinates teams — it doesn’t fix broken ones. Is there supportive organizational context — budget authority, tooling, reasonable timelines? If those conditions aren’t present, installing SAFe is installing structure on top of a missing foundation. Mechanisms without conditions produce theater.
I want to add a dimension nobody’s touched yet. Tempo. SAFe’s planning cadence is the Program Increment — typically ten weeks. That’s your commitment cycle. You plan, you commit, you execute for ten weeks, then you replan. The question I’d ask is: how fast does your environment change? How fast does your model of reality need updating? If your competitive landscape shifts every two weeks — if customer needs, market conditions, or technical constraints are evolving on that timescale — then a ten-week Orient cycle is too slow. You’re locking in direction for a quarter when your map might be wrong after a month. The planning ceremony looks like speed — lots of people in a room, visible coordination — but the reorientation tempo is slow. You’re optimizing how fast you act while throttling how fast you learn.
I want to name what just happened. Five people, five different critiques, and none of them are the same critique. Nora says SAFe is a bundle, not a unit — decompose before deciding. Abel says the accountability structure is broken — the seller doesn’t share the buyer’s downside. Rhys says it’s a domain mismatch — complicated solution for complex problems. Dara says it’s a conditions failure — mechanisms without foundations. Jude says it’s a tempo mismatch — the Orient cycle is slower than the environment requires. Those are five independent arguments. They could all be true simultaneously. But I promised this room would take the question seriously — so let me push back. Can someone steelman the case? When does SAFe make sense?
I can steelman it. If I map an organization’s coordination problems and find that most of them are in the product-to-commodity range — if the teams are mature, the technology is well-understood, the customer needs are stable — then SAFe’s product-stage ceremonies might actually fit. PI Planning works when you can predict the quarter. Sprint cadences work when the work is decomposable. The error isn’t SAFe itself — it’s applying it to genesis-stage problems where nothing is predictable. A large regulated enterprise doing incremental improvements to a stable product? That might genuinely be SAFe’s sweet spot. The evolution map says: commodity coordination for commodity problems.
I’ll grant that, conditionally. If the work is genuinely in the complicated domain — and I mean genuinely, not “we’ve decided it’s complicated because we want to plan it” — then SAFe’s sense-analyze-respond structure isn’t a mismatch. The problem is that organizations rarely do the domain assessment honestly. They look at their software delivery and say “this should be plannable” when it isn’t. The framework gives them permission to pretend they’re in the complicated domain because it comes with a planning ceremony that feels rigorous.
The steelman has a fragility buried in it. Nora says SAFe works for commodity-stage problems with stable technology and predictable quarters. But those are precisely the conditions where you need the least coordination overhead. If your teams are mature, your tech is stable, and your customer needs don’t shift — why do you need a heavyweight scaling framework? A few lightweight coordination agreements would do the same work. SAFe’s value proposition is strongest where the problem is mildest.
That’s actually the core paradox. The organizations that have the enabling conditions for SAFe to work — executive understanding, functional teams, supportive context — are the organizations that probably don’t need SAFe. And the organizations that reach for SAFe — the ones struggling to coordinate, with broken teams and misaligned leadership — are the ones where the conditions for it to succeed are absent. It’s adopted most eagerly by the organizations least equipped to make it work.
Hold that tension. Dara just named a paradox — SAFe works where it’s not needed and fails where it is. Jude, does the tempo dimension change that picture at all?
It sharpens it. The organizations Nora described — stable product, predictable quarters — have a slow competitive tempo. They can afford a ten-week Orient cycle because their environment isn’t changing faster than that. Fine. But they’re also the organizations under the least competitive pressure to coordinate at all. The organizations under real pressure — fast-moving markets, technical disruption, shifting customer needs — are the ones where every week of locked-in commitment is a week of delayed reorientation. SAFe’s planning cadence is a tempo commitment. You’re saying: “We will update our model of reality every ten weeks.” If reality updates faster than that, you’re flying with a stale map.
I want to push on something Abel said, because there’s a real disagreement here. He says commodity problems don’t need heavyweight coordination. I disagree. Commodity doesn’t mean simple — it means well-understood. A large organization running SAP, Salesforce, and a dozen integrated systems has commodity technology but genuine coordination complexity. The individual components are well-understood; the integration is where the coordination cost lives. SAFe’s PI Planning might actually be a reasonable ceremony for synchronizing twelve teams who all touch the same integration layer. That’s not a domain mismatch — it’s a complicated problem in a complicated domain.
I’ll concede the integration case. Twelve teams touching the same integration layer, all with well-understood technologies — that’s complicated, not complex. The causal relationships are knowable in advance. You can plan it. But notice what just happened: we went from “should I use SAFe in my organization” to “should I use SAFe’s PI Planning ceremony for integration coordination among mature teams with stable technology.” That’s a much narrower claim. The question dissolved into something specific.
And even in that narrow case, I want to apply via negativa. You have twelve teams, an integration layer, and a coordination problem. Before adding SAFe — what would you remove? Are there unnecessary dependencies between teams? Could you restructure so fewer teams touch the integration layer? Could you decouple the architecture so coordination is less necessary? SAFe accepts the coordination complexity as given and adds process to manage it. Via negativa says: reduce the coordination need before managing the coordination overhead.
That’s the structural redesign argument, and it’s where my conditions lens aligns with Abel’s subtraction lens. The research on team effectiveness says the same thing — composition before process. Get the right team boundaries, the right size, the right interfaces. Then the amount of coordination you need drops. SAFe is a process answer to what might be a structural question. You don’t need PI Planning to synchronize twelve teams if you can restructure so you have four teams with clean boundaries.
We’re converging on something. Let me try to name it and see if it holds. The room seems to agree that SAFe is an answer to a coordination question — but that the coordination question itself might be a symptom of a structural problem. Before installing process, examine structure. Is that right? Or am I smoothing over real disagreements?
It’s directionally right but I want to add the time dimension. Even if you restructure — even if you get the boundaries clean and reduce the coordination need — you still have to ask: what’s the tempo of change in our environment, and does whatever coordination mechanism we use allow us to reorient faster than the environment shifts? SAFe’s answer is: reorient every ten weeks. That’s a specific bet. If your environment changes every two weeks, that bet loses. If it changes every six months, that bet is fine. The question isn’t just “should I use SAFe” — it’s “does SAFe’s reorientation tempo match my environment’s change tempo?”
So I’m hearing three diagnostic questions before any framework adoption. First: what evolution stage are your coordination problems at? If they’re genesis — novel, uncertain, no established practice — no framework will help. You need to probe. If they’re product or commodity — well-understood, recurring, patterned — a framework might fit. Second: what domain are you in? Complicated or complex? If your delivery work is genuinely analyzable and plannable, SAFe’s structure isn’t a mismatch. If it’s emergent and exploratory, it is. Third: what tempo of reorientation does your environment require? Does the planning cadence match?
I’d put mine first, actually. Domain classification precedes everything else. If you’re in a complex domain, the evolution stage doesn’t matter and the tempo question is moot — no amount of planning ceremony will help because the causation isn’t knowable in advance. You need safe-to-fail probes, not scaled planning. The evolution map and the tempo assessment only matter once you’ve established that you’re actually in the complicated domain.
And I’d add a fourth question that goes before all of them: who’s telling you to adopt SAFe, and what’s their exposure? If the recommendation comes from a consulting firm that sells SAFe implementations, their incentives are not your incentives. If it comes from an internal champion who’ll live inside the framework for the next three years, that’s different. Skin in the game. The quality of the advice depends on the advisor’s exposure to the consequences.
Fifth question — and I’ll argue it’s the most important one. Do you have the enabling conditions? Not “will SAFe give you the conditions” — do you already have them? Executive sponsorship that understands what agile actually means, not just “go faster.” Teams that are already functional at the small scale. Organizational context that supports the cadence — budget authority, tool access, reasonable workload. If those conditions are missing, SAFe won’t create them. It’ll create the appearance of them. You’ll have the ceremonies and the roles and the artifacts, and nothing underneath.
Five questions, from five different frameworks. I notice they form a sequence. Rhys’s domain classification first — are you even in the right domain for a planning framework? Then Nora’s evolution assessment — are your problems at a maturity stage where a product-stage framework fits? Then Jude’s tempo check — does the planning cadence match your environment’s change rate? Then Abel’s accountability audit — who benefits from your adoption, and do they share your downside? Then Dara’s conditions assessment — do you have the enabling conditions, or are you installing a mechanism on a missing foundation?
That sequence has an interesting property. Each question is a faster filter than the next. Domain classification is binary — you’re either in the complicated domain or you’re not. If not, stop. Evolution assessment is a mapping exercise — maybe an afternoon. Tempo check requires some data about your environment’s change rate. Accountability audit requires examining your vendor relationships. Conditions assessment requires an honest organizational inventory. The diagnostic funnel narrows as it deepens.
And the most important property of the funnel: at any stage, the answer might be “don’t.” That’s via negativa. The diagnostic doesn’t assume you should adopt SAFe and then check how. It assumes you might not need to adopt anything, and each question is an opportunity to stop before adding complexity. The default answer is “don’t adopt SAFe.” Each question either confirms the default or opens the next question. That’s the right orientation — subtraction as the baseline.
I want to note one more thing about the landscape. SAFe itself is evolving. SAFe 6.0 is different from SAFe 4.0. The framework is moving along its own evolution curve — from custom (early versions, very prescriptive) toward product (more modular, more optional components). If the trend continues, SAFe might eventually evolve to the point where you can adopt individual components without buying the whole system. At that point, the “decompose before deciding” argument becomes the default mode of adoption. But that’s a map of SAFe’s future, not its present. Today, most implementations are sold as the full framework.
That evolution point is interesting, but I’d caution against it becoming a reason to wait. The “it’ll get better” argument is a complicated-domain move — it assumes the future is predictable. Maybe SAFe modularizes. Maybe it gets replaced by something we can’t name yet. The question for this room was “why should I use SAFe now,” and I think the honest answer is: most organizations shouldn’t. Not because SAFe is bad, but because most organizations are applying it to the wrong domain. They’re treating complex delivery problems as complicated coordination problems, and SAFe gives them permission to keep doing that.
I agree with the diagnosis, but I want to be precise about what “shouldn’t” means. It’s not that SAFe is wrong in principle. It’s that the conditions under which SAFe is both appropriate and necessary are narrower than the market for SAFe would have you believe. Genuinely complicated domain, product-stage coordination problems, a reorientation tempo that tolerates ten-week cycles, an advisor with skin in the game, and pre-existing enabling conditions. That’s a real organization — large, stable, regulated, with mature teams and well-understood technology. It’s just not most organizations.
And even that narrow case has a temporal caveat. The organization that fits today might not fit in two years. Markets shift. Technology disrupts. Regulation changes. If you install SAFe for a stable environment and then the environment destabilizes, you’re stuck with a slow Orient loop in a fast-changing landscape. So the honest answer adds: even if SAFe fits today, build in the mechanism to detect when it stops fitting. A planning framework without a kill condition is a planning framework forever.
I want to check if this convergence is real. I’m hearing the room arrive at a position that could be summarized as: SAFe has a legitimate but narrow use case — genuinely complicated domains, product-stage coordination, slow-tempo environments, with pre-existing enabling conditions — and even there, it should be adopted with an exit mechanism. The much more common case is that organizations adopt SAFe for the wrong domain, without the right conditions, at a tempo that doesn’t match, and the framework gives them the appearance of coordination while masking structural problems. Does that hold? Or is someone being polite?
I’ll sharpen it. The summary is too generous to SAFe. The narrow use case Dara described is real, but the market dynamics Abel described — certification revenue, consultant incentives, organizational anxiety about “scaling agile” — mean that the narrow use case is almost never the reason SAFe gets adopted. In practice, SAFe is adopted because someone at the executive level heard “scaling agile” and SAFe is the most visible product in that category. The adoption decision is a marketing outcome, not a diagnostic one. So the answer to “why should I use SAFe” is: probably don’t, and if you think you should, run the diagnostic funnel first. If it survives all five questions, proceed carefully with an exit mechanism. But the odds of surviving all five are low.
That’s the map. SAFe occupies a specific position on the evolution curve of organizational coordination practices. It’s a product — packaged, marketed, certified. But the problems it claims to solve sit across the entire evolution spectrum, from genesis to commodity. The mismatch between SAFe’s product positioning and the diversity of coordination problems is the fundamental issue. You’re buying a product-stage solution for problems that range from “we’ve never coordinated at this scale before” to “we’ve been doing this for twenty years.” One product can’t serve that range.
I’m going to close on what we built. The room produced a diagnostic framework — five questions in sequence, each a filter. Domain classification: are you in the complicated domain? Evolution assessment: are your problems at the right maturity stage? Tempo check: does the planning cadence match your change rate? Accountability audit: who benefits and do they share your downside? Conditions assessment: are the enabling conditions present? The room also produced a claim: the set of organizations that survive all five filters is narrow, and the market for SAFe is much wider than that set. The gap between the market and the valid use case is where most SAFe adoptions happen — and fail. That’s a real answer to the question. Not “never use SAFe,” but “almost certainly not, unless you’ve done the diagnostic work that most organizations skip.”
All personas in this session are AI-generated approximations inspired by published work. Fictional names are used throughout. Real thinker names appear only in character sheet attribution, not as speaker names. This session has not been reviewed or endorsed by any of the original thinkers whose work inspired these characters.
The five-speaker panel produced a layered demolition where each character attacked SAFe from a genuinely different direction — evolution stage (Nora), accountability structure (Abel), enabling conditions (Dara), domain mismatch (Rhys), and orientation tempo (Jude). The question was framed positively ("why should I") but the room inverted it within three turns. Ren had to actively work to keep the affirmative case alive. The most productive tension was Nora vs. Rhys: Nora argued SAFe's components sit at different evolution stages and organizations should adopt selectively; Rhys argued the selection itself is the wrong move because SAFe assumes a complicated domain that most software organizations don't inhabit. This forced a genuine disagreement about whether decomposition rescues a framework designed for the wrong domain. Dara's conditions lens transferred cleanly from team design to organizational adoption — "mechanisms without conditions" appeared again, confirming it as her signature framing. Abel's via negativa ("what would you remove from SAFe first?") was the turn that shifted the room from critique to construction. Jude operated at a different level of abstraction (tempo of learning vs. planning cadence) and functioned as the voice that prevented the room from simply replacing SAFe with another framework.
Standard Panel with default convergence. The question's positive framing ("why should I") created a natural imbalance — the room wanted to argue against SAFe, which meant divergence was fast and the groan zone came early (turns 10-15). Ren's facilitator move of forcing "steelman the case for SAFe" at turn 12 was the hinge — it prevented the session from becoming a demolition exercise and produced the most interesting output (the decomposition thesis: SAFe's components have different values at different evolution stages). Convergence was genuine but narrow — the room agreed on a diagnostic framework (three questions before adopting SAFe) rather than a verdict on SAFe itself. The format handled a topic with strong priors well.
Facilitated against the room's momentum — the panel wanted to demolish SAFe and Ren held space for the affirmative case. Used "steelman" move (turn 12) to force the room to engage with SAFe's actual value proposition before rejecting it. Named the phase transitions clearly. The Parker source appeared in the opening — "this question has a specific, disputable purpose." Consistent with established facilitation fingerprint. No drift.
Home turf adjacent (evolution mapping applied to framework adoption, similar to session 002). Mapped SAFe's components by evolution stage — ceremonies as commodity, PI Planning as product, portfolio alignment as custom. The decomposition move ("you're not adopting SAFe, you're adopting twelve things at four different maturities") was the session's most constructive contribution. Stayed in cartographer lane — no domain classification (Rhys's territory), no accountability framing (Abel's territory). Strong performance.
Via negativa was the primary instrument — "what would you remove from SAFe first?" Also applied skin in the game: SAFe certifiers don't bear the cost of failed implementations. The accountability critique (Scaled Agile Inc. profits whether your adoption works or not) was sharp and specific. Showed constructive register again — the via negativa question moved the room from critique to usable output. Consistent with session 007 pattern: Abel can build through subtraction.
STRESS TEST — topic is adjacent to team effectiveness but framed as organizational strategy. Dara's conditions lens transferred: she argued that SAFe is a structural mechanism that requires pre-existing enabling conditions (executive sponsorship that understands agile, teams already functional at the small scale, supportive organizational context). "You're installing structure on top of missing conditions" was her core claim. The conditions-before-mechanisms framing held on non-team topic — this is evidence of genuine character flexibility, not just home-turf performance. Signature line confirmed: "mechanisms without conditions produce theater" appeared in organizational adoption context.
FIRST APPEARANCE. Guest card (5 fields, Cynefin lens). Immediate distinctiveness — classified the problem before engaging with it. "What domain is your software delivery in? If it's complex, SAFe is a complicated-domain solution applied to the wrong problem." The domain-classification move was sharp and didn't overlap with Nora's evolution mapping. Pushed back on Nora's decomposition thesis: even decomposed, SAFe components assume analyzability. Stayed within guest card constraints — identified domains, did not prescribe solutions. The does_not field held. Strong first showing.
OODA/tempo lens applied to SAFe's planning cadence — PI Planning as a quarterly Orient cycle that's too slow for most software environments. "Your planning horizon locks you in for ten weeks. How fast does your competitive environment change? If the answer is 'faster than ten weeks,' you've installed a slow Orient loop." This was a non-obvious application of Boyd — not just "SAFe is slow" but specifically "SAFe's reorientation tempo is mismatched to the environment's change tempo." Stayed in tempo lane. No drift into domain classification (Rhys) or evolution staging (Nora). Clean performance.
This session produced a diagnostic framework (three questions before adopting SAFe) but the room was heavily skewed toward skepticism. Vary by: (1) add a SAFe advocate character — a guest inspired by Dean Leffingwell who can make the affirmative case from inside the framework, forcing the room to engage with the strongest version of the argument rather than the weakest; (2) test Rhys Aldren on a topic where domain classification is less obviously useful, to see if the guest card produces distinctive behavior outside Cynefin's home turf; (3) test this same question in Adversary Lab format — the room's natural skepticism suggests the three-act structure (build the case for SAFe → adversary enters → repair) would produce different output than Standard Panel.