Scaled Agile (SAFe and LeSS)

Definition: Scaled Agile refers to the family of frameworks that attempt to apply agile practices across many teams building one product, where the informal coordination that works inside a single team breaks down. The two dominant approaches answer the same problem in opposite directions: SAFe (Scaled Agile Framework) adds explicit structure — new roles, cadences, and planning layers above the teams — while LeSS (Large-Scale Scrum) removes structure, insisting on one Product Owner, one backlog, and one Sprint shared across all teams. Both are responses to the fact that coordination cost grows faster than headcount, and choosing between them is really a choice about whether your organization will change its shape or work around it.

How It Works

The Coordination Problem

A single Scrum team works because communication inside it is nearly free. Eight people in a room, or in one channel, can hold shared context in their heads. Nobody writes a status report to tell the person sitting next to them what they changed. The daily standup is fifteen minutes because everyone already knows most of it.

That property does not survive multiplication. The number of pairwise communication paths in a group of $n$ people is:

$P(n) = \frac{n(n-1)}{2}$

For $n = 8$ , that is 28 paths — manageable. For $n = 80$ , it is 3,160. The headcount grew tenfold; the paths grew a hundredfold. This is the arithmetic behind Brooks’s observation that adding people to a late project makes it later: the new capacity is linear, and the new coordination burden is quadratic.

Teams are the first mitigation. If you split 80 people into 10 teams of 8, most communication becomes intra-team and cheap. The expensive paths are the ones between teams, and there are only:

$P(10) = \frac{10 \times 9}{2} = 45$

of those. Forty-five inter-team relationships is far better than 3,160 individual ones, but it is not nothing — and each one is expensive, because it crosses a context boundary, involves negotiation about priorities neither team controls, and typically resolves on a timescale of days rather than minutes.

Every scaling framework is an answer to those 45 edges. The two dominant families answer in opposite directions:

Reduce the cost of each edge by adding explicit machinery to manage it: shared planning events, dependency boards, coordination roles. This is SAFe.
Reduce the number of edges by refusing to create the structures that generate them: one backlog, one Product Owner, one definition of “done,” teams that can pick up any work. This is LeSS.

There is a third answer, which neither framework centers and which the closing section returns to: change the architecture and team boundaries so that the dependencies do not exist.

How SAFe Structures It

SAFe treats scaling as an organizational design problem and solves it by adding layers. The core unit is the Agile Release Train (ART): a long-lived group of 5 to 12 teams (roughly 50 to 125 people) that plans and delivers together on a fixed cadence. The ART is a “virtual organization” — the teams keep their line managers but share a train.

The pieces that make it run:

Element	What it is	What problem it addresses
Agile Release Train	50-125 people, aligned to a shared mission and cadence	Bounds the coordination set to a fixed group
Program Increment (PI)	A fixed timebox of 8-12 weeks containing 4-5 Sprints	Creates a synchronized planning horizon
PI Planning	A 2-day, all-hands event at the start of each PI	Makes cross-team dependencies visible and negotiated in one room
Release Train Engineer (RTE)	Chief Scrum Master for the train	Owns the process across teams, removes cross-team impediments
Product Management	Owns the Program Backlog and Features	Provides a single prioritized input above team backlogs
System Architect	Owns runway and architectural direction across teams	Prevents 10 teams from making 10 incompatible choices
Program Board	Physical or digital map of features, teams, and dependency strings	Turns implicit dependencies into a visible artifact
Inspect and Adapt	Retrospective plus problem-solving workshop at PI boundary	Provides a feedback loop above the team retrospective

PI Planning is the centerpiece. Every team on the train, plus stakeholders, spends two days together. Business owners present context and priorities. Teams break Features into Stories, draft Sprint-by-Sprint plans, and physically string dependencies between teams on the program board. Risks get surfaced and categorized as resolved, owned, accepted, or mitigated. Teams state objectives, business owners assign business value to them, and the room votes on confidence. The output is an aligned, negotiated plan for the next quarter that every team has actually seen.

SAFe ships in four configurations of increasing weight, and the framework itself advises starting at the smallest one that solves your problem:

Configuration	Scope	Adds	When it is justified
Essential SAFe	One ART, 50-125 people	Teams, ART, PI Planning, RTE	The default starting point; most of the value lives here
Large Solution SAFe	Multiple ARTs on one solution	Solution Train, Solution Architect, pre- and post-PI planning	Systems too large for one train, e.g. aircraft, telecom platforms
Portfolio SAFe	Funding and strategy layer	Lean Portfolio Management, value streams, epics, Lean budgets	Budgeting and governance are themselves the bottleneck
Full SAFe	All of the above	Nothing new; the union	Very large enterprises with all of the above problems at once

The larger configurations are where most criticism lands, and also where most of the enterprise appeal sits. Portfolio SAFe exists to replace annual project funding with persistent value-stream funding — a genuinely important change — but it does so by adding vocabulary and roles that finance and audit can recognize, which is exactly the move critics read as bureaucratic and defenders read as pragmatic.

Cadence, Synchronization, and the Integration Surface

Underneath both frameworks sits the same mechanism, and it is worth separating from the ceremony wrapped around it: synchronized cadence bounds the integration surface.

When teams work on independent rhythms, the moment at which two changes meet is unpredictable. Team A finishes an interface change on a Tuesday; Team B discovers it three weeks later when it starts consuming the endpoint. The cost of the collision scales with how long it went undetected. When teams share a cadence, collisions are structurally forced to surface at a known boundary.

SAFe and LeSS place that boundary in different places:

Property	SAFe	LeSS
Planning boundary	PI, every 8-12 weeks	Sprint, every 1-4 weeks
Integration expectation	System Demo each Sprint; full solution demo at PI	Continuous integration into one trunk, all Sprint
Slack for the unknown	Innovation and Planning Sprint at PI end	Absorbed inside the Sprint; no dedicated buffer
Feedback latency on plan quality	One quarter	One Sprint

That last row is the substantive difference. LeSS gets an empirical signal about whether its plan was right every Sprint. SAFe gets a strong one every increment. Defenders of SAFe note that Sprint-level inspection still happens inside the train; critics note that the thing being committed to publicly — the PI objectives — is inspected on a quarterly loop, and a control system that samples quarterly cannot correct faster than that.

The Innovation and Planning Sprint deserves specific mention because it is frequently abused. It is intended for innovation, learning, and the next PI Planning event. In practice it becomes a hardening Sprint where the integration work that should have happened continuously gets crammed in. When a team’s IP Sprint is reliably full of bug fixing and integration, that is a direct measurement of missing engineering practice, not a scheduling detail. See CI-CD Best Practices.

How LeSS Structures It

LeSS starts from the opposite premise: scaling frameworks that add roles and layers reintroduce exactly what Scrum was designed to remove. Its design rule is that LeSS should be Scrum applied to many teams, not a new framework. Almost nothing is added; a great deal is removed.

The core rules:

One Product Owner for the whole product, not one per team. The PO works with all teams, holds priority, and is deliberately kept from becoming a full-time requirements writer — teams talk to users and stakeholders directly.
One Product Backlog across all teams. There are no team backlogs. Items are pulled from the single ordered list.
One Sprint, synchronized. All teams start and end together. There is one potentially shippable increment at the end, integrated continuously throughout — not integrated at the end.
One Definition of Done shared by every team, which prevents “done” from meaning different things and creating hidden integration debt.
Feature teams, not component teams. Teams are cross-functional and cross-component: any team can, in principle, take any item from the top of the backlog. This is the structural move that removes dependencies rather than managing them.
No new roles. No RTE, no program manager, no Chief Product Owner in basic LeSS. Coordination happens through practices, not positions.

Coordination in LeSS is deliberately informal and just-in-time:

Sprint Planning One is a joint session where representatives from each team select items and identify shared work. Sprint Planning Two happens per-team, in parallel.
Communicate in code. Continuous integration on a shared codebase surfaces conflicts within hours, not at a quarterly boundary.
Travelers and scouts. People visit other teams to spread knowledge; observers attend another team’s daily scrum.
Communities of Practice carry cross-cutting concerns (architecture, testing) without becoming a governing layer.
Overall Retrospective looks at system-level impediments after the per-team retrospectives.

LeSS Huge extends this to more than eight teams by adding Requirement Areas — customer-centric slices of the product, each with an Area Product Owner and an Area Backlog that is a view onto the single Product Backlog. Even here, the additions are minimal and deliberately customer-facing rather than functional.

The Structural Contrast

The diagram makes the tradeoff visible. SAFe interposes machinery between strategy and teams; each layer is a place where alignment can be enforced and also where information can be lost or delayed. LeSS collapses the path — there is one backlog and one cadence — but that only works if teams are genuinely capable of taking any item, which is a much deeper organizational demand than adding a role.

How Dependencies Actually Get Handled

Why It Matters

Coordination cost is the real constraint on large software organizations, not individual productivity. A tenfold increase in headcount rarely produces a tenfold increase in delivered value, and the gap is almost entirely coordination overhead. Frameworks are attempts to bend that curve.
Ignoring the problem does not make it go away. Organizations that scale by simply adding more Scrum teams without any cross-team mechanism get integration hell: teams that are individually “done” and collectively shipping nothing. Something has to handle the seams.
The choice reveals what an organization is actually willing to change. SAFe can be adopted without redrawing reporting lines or rebuilding the architecture. LeSS cannot. Which one an organization picks is often a more honest signal of its appetite for change than any transformation charter.
Governance and budgeting are real constraints, not just bureaucracy. Public companies, regulated industries, and government contractors have audit, forecasting, and capital-allocation obligations. SAFe’s portfolio layer exists because those obligations exist; a framework that ignores them will be ignored in turn.
Synchronized cadence has genuine value independent of ceremony. When every team plans and integrates on the same rhythm, the integration surface is predictable. Both frameworks converge on this — SAFe through the PI, LeSS through the shared Sprint.
Visible dependencies beat invisible ones. Whatever you think of PI Planning as an event, the program board makes cross-team commitments explicit and public. Most large organizations’ default state is dependencies that surface as a surprise three days before a release.
Scaling frameworks are architectural in disguise. You cannot have feature teams that take any item from one backlog if the codebase is a monolith with three people who understand each module. The framework question is downstream of the Team Topologies and Conway’s Law question.
Poorly executed scaling is worse than none. A framework adopted as vocabulary — renaming project managers to RTEs, calling quarterly planning a PI — adds overhead without changing behavior, and burns organizational credibility on the word “agile.”
The market has made this a career skill. SAFe in particular is widespread enough in large enterprises that its terminology is a de facto lingua franca; understanding its structure is useful even for practitioners who prefer other approaches.

The Debate, Stated Fairly

This is the most contested topic in modern software process, and both sides have substance. Presenting only one is a disservice.

The case for SAFe

It is prescriptive enough to actually implement. “Descale your organization and build feature teams” is good advice that gives a VP no Monday-morning action. SAFe gives a sequence: train the leaders, launch a train, run a PI. Prescriptiveness is a feature when the alternative is paralysis.
It provides a legible transition path. Existing managers, architects, and program managers can see where they fit. That matters, because transformations die when the people with power to stop them conclude they have no future in the new model.
It speaks the language of the enterprise. Lean Portfolio Management maps onto annual budgeting, capitalization rules, and audit trails. A framework that requires finance to abandon its operating model will not be adopted by finance.
PI Planning genuinely works as a communication event. Getting 100 people who build one system into one room for two days a quarter surfaces misalignments that would otherwise take months to detect. Many teams report the event itself is the most valuable part regardless of the surrounding framework.
It is explicitly incremental. Essential SAFe is a much smaller commitment than full Portfolio SAFe, and the framework tells you to start there.

The case against SAFe

The added layers recreate the hierarchy Agile was reacting against. The Agile Manifesto valued individuals and interactions over processes and tools; a framework with a large role taxonomy and a multi-page diagram is at minimum in tension with that. Critics argue the layers reinstate command-and-control with new job titles.
Quarterly PI planning can function as a re-skinned stage gate. If a team commits to a set of objectives for the next 10 weeks and business owners assign value to them, the practical effect can resemble a phase plan — which is precisely what iterative development was meant to replace. Defenders respond that PI objectives are meant to be revised mid-increment; critics respond that in practice they rarely are, because the commitment was made publicly to executives.
It permits component teams and thereby preserves dependencies. SAFe manages dependencies well. LeSS advocates argue that managing a dependency is a consolation prize for failing to eliminate it, and that a framework which makes dependencies tolerable removes the pressure to fix their cause.
The certification and consulting economy creates incentive problems. A framework whose adoption is mediated by a paid training ecosystem faces reasonable questions about whether its complexity serves practitioners or the ecosystem.
Adoption quality varies enormously. Much criticism aimed at SAFe is really aimed at bad SAFe implementations. That is a fair defense, but a framework routinely implemented badly at scale has a design problem worth examining, not just a training problem.

The case for and against LeSS

LeSS’s strength is coherence: it stays close to Scrum’s empirical core, and its rules follow from a single principle. One backlog, one Sprint, one Done. It refuses to let structure paper over a broken system, and its emphasis on feature teams attacks the dependency problem at the root.

Its cost is that it demands what most enterprises will not give. Real LeSS adoption means dissolving component teams, changing what managers do (LeSS reframes managers as improvers of the system rather than assigners of work), often reorganizing reporting structures, and investing years in the technical practices — continuous integration, shared code ownership, strong test automation — that make “any team can take any item” true rather than aspirational. Organizations that adopt LeSS as a label while keeping component teams and per-team backlogs get all the disruption and none of the benefit. LeSS is honest about this; it says outright that it requires organizational change rather than process veneer. That honesty is also why its adoption is far narrower.

Comparison

Dimension	SAFe	LeSS	Scrum@Scale	Spotify Model (as popularized)
Core move	Add coordinating structure	Remove structure; descale	Scale by fractal replication of Scrum	Describe an org shape; not a framework
New roles	Many: RTE, Product Mgmt, System Architect, Epic Owner, LPM	Almost none; Area PO only in LeSS Huge	Scrum of Scrums Master, Chief Product Owner	Tribe Lead, Chapter Lead, Guild coordinator
Planning cadence	PI Planning every 8-12 weeks, plus Sprints	One synchronized Sprint; no separate big-room event	Scaled daily scrums; scaled events per cycle	Not prescribed
Backlog structure	Portfolio to Program to Team backlogs	One Product Backlog for all teams	One product backlog per Product Owner tree	Not prescribed
Prescriptiveness	High — detailed roles, events, artifacts	Low in additions, high in principles	Medium — a minimal scaling pattern	Very low; descriptive snapshot
Team structure	Permits component and feature teams	Feature teams required	Cross-functional teams expected	Squads owning a slice
Governance fit	Strong; designed for enterprise finance and audit	Weak; assumes leadership will change budgeting	Moderate	None provided
Typical scale	50-125 per ART; thousands via portfolio	2-8 teams; LeSS Huge beyond	Any, by recursion	Company-specific
Best fit	Large regulated enterprises needing a legible path	Product organizations willing to restructure	Orgs already strong in Scrum wanting minimal addition	Nobody, as a copy-paste target
Main risk	Layers ossify; PI becomes a stage gate	Adoption stalls when restructuring is refused	Under-specification leaves gaps	Cargo-culting a snapshot of one company in 2012

A note on the fourth column: the “Spotify Model” was a description of how one company worked at one moment, published by its own authors with the caveat that it was not a framework. It became the most copied non-framework in the industry. Spotify itself moved on. Copying an org chart without the culture and technical practices underneath it is the purest form of the mistake all four columns can suffer from.

Choosing an Approach

The framework question is almost never decided on technical merit. It is decided by how much structural change the organization will genuinely tolerate, and pretending otherwise produces adoptions that fail for reasons nobody named up front. A blunt set of decision criteria:

If this is true of your organization	Lean toward
Two or three teams on one product	Neither framework; a shared Sprint and one backlog is enough
Regulated industry with audit and traceability obligations	SAFe, likely Essential only
Annual project funding is the real bottleneck	SAFe Portfolio layer, adopted deliberately
Leadership will actually dissolve component teams	LeSS
Codebase is a monolith nobody can safely change	Neither yet; architectural work first
Existing Scrum practice is strong at the team level	LeSS or Scrum@Scale
Existing Scrum practice is weak or nominal	Fix the team level before scaling anything
Hundreds of people, many products, shared platform	SAFe for coordination plus platform teams for descaling
Hardware or third-party milestones you cannot move	SAFe; the PI boundary is a natural sync point

The honest summary: SAFe is what you choose when the organization will not change shape and you need delivery to work anyway. LeSS is what you choose when it will. Both are legitimate answers to different constraints, and misdiagnosing which constraint you are under is the most expensive mistake available here.

Measuring Whether It Is Working

Adoption success is routinely measured with framework-internal metrics, which reward compliance rather than outcomes. A more useful measurement set separates the two:

Metric	What it tells you	Failure mode when optimized directly
Lead time, commit to production	Whether the system actually delivers faster	Hard to game; the best single signal
Deployment frequency	Whether integration is real or ceremonial	Can be gamed with trivial deploys
Change failure rate	Whether speed came at the cost of stability	Discourages risk-taking if used punitively
Cross-team dependency count per increment	Whether the structural problem is shrinking	Teams stop reporting dependencies
Time to resolve a cross-team dependency	The actual coordination cost	Rushed handoffs
Percentage of items a random team could take	Real progress toward feature teams	Self-reported and optimistic
PI predictability, story points delivered	Compliance with the plan	Estimate inflation; teams sandbag to look reliable
Ceremony attendance, certification counts	Nothing about delivery	Pure theater

The top rows measure the system. The bottom rows measure the framework. When an organization reports a successful transformation using only the bottom rows, that is the finding. Note also that Velocity and Burndown Charts do not aggregate meaningfully across teams — comparing team velocities is a category error, since points are a team-local unit, and using them to rank teams reliably destroys their estimating honesty. See Story Points and Estimation.

Real-World Use Cases

A retail bank modernizing core payments runs three ARTs of about 90 people each. Regulatory reporting requires forecastable delivery windows and traceable change approval; PI Planning provides the quarterly artifact auditors ask for, and the program board doubles as evidence of dependency management.
An automotive supplier building embedded control software uses SAFe alongside a V-Model safety process because ISO 26262 requires verification traceability. Agile execution inside teams; PI boundaries as the synchronization point with hardware milestones that genuinely cannot move.
A medical device firm aligns PI cadence to design-history-file checkpoints, keeping Definition of Done identical across teams so that “done” always includes the documentation the regulator will read.
A SaaS company with six teams on one product adopts LeSS: one Product Owner, one backlog, one two-week Sprint, continuous integration into a single trunk. Cross-team dependencies mostly vanish because any team can touch any part of the codebase.
A telecom operator launches an ART spanning network provisioning, billing, and customer portal teams — three groups that previously coordinated through ticket queues with multi-week latency. The measurable win is not velocity but dependency resolution time.
A government digital services agency uses Essential SAFe only, deliberately skipping the portfolio layer, to satisfy oversight requirements without importing the full role taxonomy.
A gaming studio with four platform teams rejects both frameworks and instead reorganizes around Team Topologies and Conway’s Law, creating a platform team that provides self-service tooling so stream-aligned teams stop filing requests at each other.
A logistics platform starts with SAFe to survive a merger integration, then progressively removes layers over two years as the codebase is decomposed and teams become genuinely cross-component — using SAFe as scaffolding rather than a destination.
An insurance carrier discovers during PI Planning that four teams had independently planned changes to the same rating engine module. The event’s value was not the plan; it was catching the collision before three of the four wasted a quarter.

Common Pitfalls

Adopting the vocabulary without the behavior. Renaming the PMO to Lean Portfolio Management and the project plan to a PI plan changes nothing. If the same people make the same decisions on the same evidence, the transformation is a rebranding exercise with a training invoice attached.
Treating a scaling framework as the fix for architectural coupling. If four teams must coordinate because they all edit the same 400,000-line module, no amount of PI planning addresses the cause. You are paying a recurring coordination tax to avoid a one-time refactoring cost. See Code Refactoring and Technical Debt.
Letting PI objectives harden into contracts. The moment a business owner treats a 10-week objective as a commitment that cannot change, the increment becomes a phase and you have rebuilt the Waterfall Model with better stationery. Objectives should be revisable on new information; if they never are, inspect why.
Keeping component teams while claiming feature teams. A “feature team” that must file a request with the database team to ship anything is a component team with a new label. This single compromise defeats most of the benefit LeSS is designed to deliver.
Multiplying Product Owners. One PO per team sounds scalable and produces divergent priorities, duplicated work, and local optimization. LeSS’s insistence on a single PO is the direct countermeasure; SAFe’s Product Management layer is the alternative countermeasure. Having neither is the failure mode.
Scaling before the fundamentals hold. If single teams cannot maintain a Definition of Done, keep a healthy Product Backlog and Refinement cadence, or run reliable CI-CD, scaling multiplies the dysfunction. Fix the team level first; a scaling framework amplifies whatever is already there.
Measuring the framework instead of the outcome. Tracking PI predictability, story point throughput, or ceremony attendance measures compliance. Lead time, deployment frequency, change failure rate, and escaped defects measure delivery. Optimizing the first set reliably degrades the second — teams inflate estimates to hit predictability targets.
Ignoring the technical practices. Both frameworks assume continuous integration, automated testing, and trunk-friendly workflows. Without them, “one integrated increment” is a fiction maintained by an integration team working weekends. See Test Pyramid and TDD and CI-CD Best Practices.
Big-bang rollout across the whole organization. Launching twelve ARTs simultaneously guarantees that nobody has learned anything before it is everywhere. Start with one train or one product group, learn, and expand.
Never removing scaffolding. Coordination structures added during a difficult period should be reviewed and dismantled when the underlying need is gone. Layers rarely remove themselves; someone’s job now depends on each one.

The Third Answer: Reduce the Dependencies

Here is the strongest honest point in this entire note, and it undercuts the framing of the framework debate.

SAFe and LeSS both take the dependency graph as roughly given and optimize against it. SAFe makes each dependency cheaper to manage: surface it, plot it, assign it an owner, resolve it on cadence. LeSS makes fewer dependencies reach the coordination layer, because a feature team can absorb the work end to end instead of handing it off. Both are working on the cost side of the equation.

Team Topologies and Conway’s Law proposes something different: change the graph. Conway’s Law observes that systems mirror the communication structures of the organizations that build them. Read in reverse — the “inverse Conway maneuver” — it says that if you want a particular architecture, organize the teams to match it, and if you want fewer inter-team dependencies, draw team boundaries along the seams where coupling is genuinely low. A stream-aligned team owning a full vertical slice with a well-defined interface to a platform team has almost no dependencies to coordinate. There is nothing to plot on a program board.

The uncomfortable implication: a large fraction of organizations adopting a scaling framework are treating a symptom. The dependency load that makes coordination expensive is usually generated by architectural coupling — a shared database, a monolith with no internal boundaries, a service everyone must change to ship anything, a single team gatekeeping deployments. The framework does not touch any of that. It builds a very capable apparatus for managing pain that better module boundaries would have prevented.

This is not an argument that scaling frameworks are useless. Three things are true at once:

Some dependencies are irreducible. Regulatory sign-off, hardware schedules, third-party integrations, and genuine domain coupling do not yield to refactoring. Coordination machinery is the right tool for those.
Architectural change is slow, and delivery cannot pause. A framework can be the scaffolding that holds an organization together while decomposition happens underneath. Used deliberately, that is sound engineering management.
Frameworks can hide the signal that would drive the fix. When PI Planning makes dependencies survivable, the pain that would have funded the refactoring dissipates. The board is full of strings every quarter, and everyone treats that as normal rather than as a diagnostic.

The practical synthesis: read the dependency board as an architecture report. If the same two teams are connected by strings every single increment, that is not a coordination finding — it is a module boundary in the wrong place. If one team appears in half of all dependencies, that team is a bottleneck, and the fix is to turn its work into a self-service platform, not to schedule it more carefully. If the strings thin out over successive increments, decomposition is working. If they thicken, the framework is absorbing pain that should have been forcing change.

Scaling frameworks manage the cost of dependencies. Team and system design can reduce the dependencies themselves. The first is a control system; the second is a cure. Most organizations need both, in that order — but only one of them is on the certification track, which is a fair part of why the industry keeps reaching for it first.

Example

A payments company grew from 30 engineers to 140 in eighteen months. The product was one Java monolith with a shared Postgres schema. As headcount rose, throughput flattened and then declined. The diagnosis in the leadership offsite was “we need to scale agile,” and the decision was SAFe: two Agile Release Trains, an RTE for each, and the first PI Planning event scheduled for the following quarter.

The first PI Planning was, by most accounts, revelatory — and not in a comfortable way. The program board ended the second day nearly opaque with dependency strings. Six of the nine teams needed schema changes from the two engineers who understood the core ledger tables. Four teams had independently planned work on the settlement module. The release process required a coordinated deploy of everything at once, so the last Sprint of every increment was reserved for integration and stabilization. The framework had done exactly what it promised: it made the true state of the system visible for the first time. What it made visible was that the organization did not have a coordination problem so much as an architecture problem wearing a coordination problem as a costume.

The RTEs made a decision that most SAFe adoptions do not make: they treated the program board as a measurement instrument rather than a plan. Each PI, they photographed the board and counted strings by team pair. The three hottest pairs became architectural work items funded as enabler features and given explicit capacity — not squeezed in as “tech debt” between customer commitments. Over five increments, the ledger schema was placed behind a versioned service with a stable interface, settlement was extracted into a separately deployable component, and the deploy pipeline moved from one coordinated release to independent per-service deploys behind Feature Flags. String count on the board fell from over sixty to roughly a dozen. Two teams, now owning genuinely independent slices, stopped needing the coordination layer at all and were quietly allowed to run outside the train’s planning event, syncing only on shared interfaces. The company never formally adopted LeSS, and it never fully exited SAFe either. What it did was use the framework as scaffolding — visible dependency accounting that funded the architectural work — and then remove the scaffolding where the building could stand on its own. The framework was not the cure. It was the instrument that made the disease legible enough to treat.

Referenced by

Dig deeper

Spot an error in this note?