Your ARTs Are Drawn Around Org Charts, Not Value Streams — And That's Why PI Planning Feels Like Theatre

Most SAFe implementations don't fail because the framework is wrong. They fail because someone drew the Agile Release Train boundaries on a whiteboard that already had the org chart on it — and never erased the lines.

It's May 2026, and if you've been running SAFe for three or more years, you already know the feeling. PI Planning happens every ten weeks like clockwork. The room is booked. The facilitators are prepped. The dependency board fills up with red strings that look like a conspiracy theorist's bedroom wall. Teams negotiate, horse-trade, and leave with "committed PI objectives" that everyone quietly knows will be renegotiated within three sprints.

The ceremony runs. The outcomes don't arrive.

I've spent the last several years coaching scaled agile implementations across Nordic financial services, public sector IT, and telco — and I'll say it plainly: misaligned ART boundaries are the single most under-diagnosed cause of scaled agile stall. Not missing roles. Not insufficient training. Not tooling. The boundaries themselves.

The good news? You don't need a full reorganisation to fix this. But you do need to see the problem clearly before you can act on it. Let me show you what to look for and what to do about it.

How ART Boundaries Go Wrong in the First Place

The Scaled Agile Framework is explicit about this: Agile Release Trains should be organised around value streams — the sequence of activities that delivers value to a customer or internal user. SAFe's own guidance says to start with an operational or development value stream analysis before you draw a single ART boundary.

In practice, almost nobody does this.

Here's what actually happens during a SAFe implementation. A consultancy comes in. They run a two-day workshop. They need to define ARTs — groups of 50–125 people who will plan and deliver together. Someone pulls up the org chart. The VP of Engineering has four departments. Each department has roughly the right number of people. Someone says, "What if each department is an ART?" The room nods. It's neat. It's fast. It doesn't require any difficult conversations about reporting lines or budget ownership.

Value stream mapping gets skipped in favour of org-chart convenience.

This isn't laziness — it's path-of-least-resistance organisational physics. Drawing ART boundaries that cut across existing reporting structures requires executive sponsorship, political capital, and a willingness to say that the current structure doesn't reflect how value actually flows. Most implementation teams don't have that mandate. So they draw lines that match the boxes that already exist.

The result is an ART structure that optimises for resource management (who reports to whom) rather than flow (how work moves from idea to customer value). And this single decision — often made in week two of a SAFe implementation — becomes the invisible ceiling on every improvement effort that follows.

Three Signals Your ART Is Drawn Wrong

You don't need a six-month assessment to diagnose this. There are three observable signals that show up reliably when ART boundaries are misaligned with actual value delivery. If you recognise two out of three, you have a boundary problem.

Signal 1: Cross-ART Dependencies Dominate Your PI Board

Look at your programme board after PI Planning. Count the dependency threads. If more than 30–40% of your features have dependencies on teams in other ARTs, your boundaries are wrong.

This is the most visible symptom. When an ART doesn't contain all the capabilities needed to deliver its value, every PI Planning event becomes a coordination negotiation between trains. The dependency board isn't a planning tool anymore — it's a map of all the places where your ART boundary cuts through the middle of a value stream.

The human cost is real. Teams spend hours in PI Planning negotiating handoffs that shouldn't exist. Product Managers become full-time dependency brokers. And the "confidence vote" at the end of PI Planning becomes a polite fiction — everyone votes three or four fingers because they know the cross-ART dependencies are the actual risk, and those are outside their control.

Signal 2: Team-Level Velocity Is High, but Programme-Level Throughput Is Flat

This is the more insidious signal. Individual teams are completing stories. Sprint burndowns look healthy. Velocity is stable or improving. But when you zoom out to the programme level — actual features delivered to customers per PI — the number is flat or declining.

This is the hallmark of local optimisation without global flow. Teams are busy. They're productive within their own context. But because the ART boundary doesn't encompass a complete value stream, completed work from one team sits waiting for another team (often in another ART) to do their part. Work-in-progress accumulates at the boundaries. Lead time from idea to delivery stretches. And the organisation experiences the paradox of high activity with low throughput.

If your Scrum Masters are celebrating velocity improvements while your Product Management is frustrated that nothing ships, this is almost certainly why.

Signal 3: PI Objectives Are Feature Lists, Not Business Outcomes

Pull up your last set of committed PI objectives. Read them. Do they describe business outcomes that a non-technical stakeholder would understand and care about? Or do they read like a backlog of technical features and component deliverables?

When ARTs are aligned to value streams, PI objectives naturally express themselves as customer or business outcomes: "Launch self-service claims process for segment X," "Reduce onboarding time from 14 days to 3 days," "Enable real-time transaction monitoring for DORA compliance."

When ARTs are aligned to org-chart components, PI objectives devolve into feature lists: "Deliver API v2.3," "Complete database migration phase 2," "Implement authentication module." These aren't outcomes — they're outputs. They're components of value that can't be realised until someone else, somewhere else, does their part.

When your PI objectives require an architect to explain why they matter, your ART doesn't own a value stream.

Why Nordic and Danish Enterprises Are Especially Exposed

This isn't an abstract problem. It has a specific geography and timeline.

SAFe was adopted heavily across Nordic enterprises — particularly in Danish financial services, public sector IT, and telecommunications — during the 2019–2022 wave. Organisations like banks, pension funds, government agencies, and telco providers moved to SAFe at scale, often driven by the need to coordinate large IT portfolios and demonstrate structured delivery governance.

Many of these implementations were done well in terms of ceremony adoption. Roles were filled. PI Planning was established. Tooling was deployed. But the foundational value stream analysis was frequently shallow or skipped entirely. ART boundaries were drawn around existing IT departments or project-based team groupings. The implementations were structurally sound on paper and misaligned in practice.

Now, three-plus years in, these organisations are hitting what I call the plateau of disappointment. The framework is running. The ceremonies happen. But delivery outcomes aren't improving at the rate the investment promised. The State of Agile report from Digital.ai and the ThoughtWorks Technology Radar have both flagged ART misalignment and ceremony overhead as the dominant scaled agile failure mode heading into 2026. This matches what I see on the ground in Copenhagen, Stockholm, and Oslo.

The NIS2/DORA Compliance Layer

Making matters worse, 2025 brought the enforcement of NIS2 and DORA compliance obligations across financial services and critical infrastructure. These regulations require structured governance, documented risk management, and clear accountability chains for operational resilience.

In organisations where ART boundaries are well-aligned to value streams, adding compliance governance is relatively straightforward — you're layering accountability onto structures that already reflect how value and risk flow. But in organisations where ARTs mirror the org chart, DORA and NIS2 compliance becomes another governance layer bolted onto already-misaligned structures. The result is more overhead, more coordination cost, and more ceremony — without more clarity or control.

Danish CIOs heading into H2 2026 planning cycles are facing a compounding problem: scaled agile that isn't delivering on its promise, plus regulatory governance that's adding weight to structures that were never designed to bear it. The urgency to address ART alignment isn't theoretical anymore. It's operational.

Three Structural Moves Short of a Full Re-Org

Here's where leaders often get stuck. They see the problem but assume the solution requires a full organisational restructure — new reporting lines, new budget centres, new VP-level negotiations. That's a twelve-month programme with significant political risk and no guaranteed outcome.

There are three structural moves you can make that address ART misalignment directly, without triggering a full re-org. Each can be initiated within a single PI cycle.

Move 1: Re-Draw ART Boundaries Using Flow Metrics, Not Headcount

The original sin was drawing boundaries based on who reports to whom. The correction is to draw boundaries based on how work actually flows.

Start with your last three PIs of data. Map every feature that was delivered (or attempted) and trace the teams that touched it. You'll see clusters — groups of teams that consistently collaborate to deliver the same types of customer value. These clusters are your actual value streams, regardless of what the org chart says.

Now compare these clusters to your current ART boundaries. Where do they match? Where do they diverge? The divergence points are your dependency generators.

You don't need to change reporting lines to change ART boundaries. An ART is a planning and delivery construct — it defines who plans together, demos together, and inspects-and-adapts together. You can re-draw ART boundaries to match flow clusters while leaving management reporting lines intact. This is politically easier than it sounds, because you're not changing anyone's boss — you're changing who they plan with.

This is the kind of structural analysis where experienced agile coaching makes a measurable difference — not coaching teams on stand-up mechanics, but helping leadership see and act on the flow patterns that the current structure obscures.

Move 2: Introduce a Lightweight Value Stream Health Check Before the Next PI

Before your next PI Planning event, run a focused value stream health check. This isn't a six-month transformation assessment. It's a structured two-week diagnostic that answers three questions:

1. Flow efficiency: What percentage of total lead time is active work vs. waiting time? (Waiting time that occurs at ART boundaries is your direct measure of boundary misalignment.)

2. Dependency ratio: What percentage of PI features require cross-ART coordination? (Track this over time — if it's increasing, your boundaries are diverging further from your value streams.)

3. Outcome alignment: Can each ART articulate a customer-facing outcome it owns end-to-end? (If not, it's a component team at scale, not a value stream ART.)

Present the results to your Release Train Engineers and Product Management before PI Planning. Let the data reframe the conversation. Often, the people closest to the work already know the boundaries are wrong — they just need permission and evidence to say it out loud.

This kind of diagnostic work sits at the intersection of PMO governance and agile delivery — it requires both the rigour of structured programme oversight and the agile sensibility to act on what the data reveals without over-engineering the response.

Move 3: Replace Feature Teams with Persistent Product Crews Aligned to Customer Journeys

This is the most significant of the three moves, but it's still short of a full re-org.

Many SAFe implementations organise teams around features — temporary groupings that form and reform based on what's in the backlog. This made sense in the project-based world, but it undermines the continuity and ownership that scaled agile requires.

The alternative is persistent product crews — stable, long-lived teams that own a specific segment of a customer journey. Not a component. Not a layer. A journey. "New customer onboarding." "Claims processing." "Merchant payment reconciliation." "Citizen self-service applications."

When teams are persistent and journey-aligned, three things happen:

• They build deep domain knowledge that accelerates delivery over time.

• They own outcomes, not outputs, because they can see the customer impact of their work.

• They reduce cross-team dependencies because the journey — not the component — defines their scope.

This doesn't require changing reporting lines. It requires changing how teams are composed and what they're accountable for. It's a project management shift as much as an agile one — moving from project-based team allocation to product-based team persistence.

What 'Real' PI Planning Looks Like When ARTs Are Right

I want to close with a picture of what's possible, because too many leaders have only ever seen PI Planning as a coordination marathon. They assume that's what it is. It's not. That's what it looks like when the boundaries are wrong.

When ARTs are aligned to actual value streams, PI Planning transforms:

Fewer cross-team dependencies. When the ART contains all the capabilities needed to deliver its value stream, most dependencies are within the ART — visible, manageable, and resolvable in the room. The dependency board has threads, but they're manageable. Teams can make real commitments because the risks are within their collective control.

Faster risk identification. When teams understand the end-to-end value stream they serve, they spot risks earlier and more accurately. They're not guessing about what another ART might or might not deliver — they own the full picture. Risk discussions in PI Planning become specific and actionable rather than abstract and defensive.

Objectives that non-technical stakeholders can commit to. This is the real test. When a business sponsor sits in PI Planning and hears the objectives, can they understand them? Can they see the customer impact? Can they make a meaningful commitment to support them? If yes, your ARTs are aligned. If they're nodding politely while mentally translating technical jargon, they're not.

PI Planning becomes a genuine alignment event rather than a coordination ceremony. People leave energised rather than exhausted. The confidence vote reflects actual confidence. And the ten-week increment that follows delivers measurable progress against outcomes that matter.

The Conversation to Have Before H2 2026

If you're a Danish CIO, transformation lead, or delivery executive heading into H2 2026 planning, here's my direct recommendation: before you plan your next PI, diagnose your ART boundaries.

Don't commission a twelve-month assessment. Don't hire a consultancy to redesign your org chart. Run the three-signal diagnostic I described above. Look at your dependency ratios, your throughput data, and your PI objectives. If two out of three signals are present, you have a boundary problem — and no amount of coaching, tooling, or ceremony improvement will fix what is fundamentally a structural issue.

The framework isn't wrong. Your implementation isn't failed. But the lines were drawn in the wrong place three years ago, and every PI since then has been working around that original mistake.

It's fixable. And it's fixable without blowing up the org chart. But it requires leaders who are willing to look at the structure itself — not just the practices running inside it.

That's not theatre. That's transformation.

Jacob Plejdrup is a senior consultant specialising in agile leadership, programme governance, and organisational design for scaled delivery. He works with Nordic enterprises navigating the intersection of agile transformation, regulatory compliance, and sustainable delivery performance.