From Features to Outcomes: Where SAFe Teams Belong When Agents Write the Code

TL;DR

• In many SAFe adoptions, teams own an application and deliver features, while the business funds outcomes that often need several teams, sometimes across ARTs.
• Agents can make feature teams faster, but faster features do not automatically mean faster outcomes. If team mandates stay the same, more of people's time may go into reviewing what agents produce, which is harder to show as value.
• A low-risk way to start: map one real outcome, see how long it takes and how often work passes between teams, then set up one of three org models for the agentic age: fluid teams, a leading team or a team-of-teams.

Every Feature Done, the Outcome Missed

Picture a mid-size insurer that runs SAFe. This year its strategy slide has one line that everybody remembers: claims under €1,000 are paid out on the same day. In the Solution Train backlog, that line becomes a SAFe Capability called "same-day payout."

Then the decomposition starts. The SAFe Capability splits into features: a new claim form in the customer app, a fraud score in the risk engine, a payment instruction in the finance integration, a status notification, a rule change in the policy system. Each feature lands with a different team, because each team owns a different application. Two ARTs are involved, five teams in total. PI Planning produces a program board with red strings across it, and everyone handles it very professionally.

One PI later, every feature is done and demoed. Claims are still paid out in four days, because the slowest step was a manual check that none of the five teams owned.

Every team delivered what it was asked for, and the outcome was missed.

(The insurer is an illustration, assembled from patterns we see in our work; the details are invented.)

Why the Agentic Shift Raises the Stakes

The agentic shift is what happens to product development once AI agents take on a real share of the work: narrow specialists can become complete craftspeople, and teams can move from counting output to owning outcomes. In practice, it can make teams more relevant, because they get to work directly on what matters to the business and its customers. That takes two moves. The first one is already happening in many teams: a team that used to wait for a database specialist or a tester can now get a good part of that work done with an agent at its side. The team becomes more complete in skills. The second move changes what the team is responsible for and sees as its job. Instead of delivering a feature into its own application and handing the rest to other teams, as in the old paradigm, the team of the agentic age takes on a result the business cares about, such as faster payouts or fewer lost customers, and works across whatever applications that result touches.

Notice: neither move is held back by technology anymore. The technology has arrived. What is left are organizational decisions, and they belong to leaders: which outcomes teams own, which boundaries they may cross, and what they are allowed to change. Agents do not make those decisions for you.

Now look at what is left for a team whose mandate has not moved with the times. If its work is still a feature inside its own application, the agent writes more and more of the code, and the people spend their days reviewing pull requests the agent generated. How long will that last? The frontier labs train their models hard on coding, and the harnesses around those models keep getting better, so the share of generated code that is good enough keeps growing, and the need for review shrinks with it. When the people in a team add nothing the agents cannot do, the organization starts to see them as a cost, and costs get minimized.

The human value moves up, to the results the business and its customers care about, and only if the teams are allowed to own them. For leaders in a SAFe organization, that becomes the real question: how do we evolve our organization so that our teams own outcomes and stay relevant in the agentic age?

Where SAFe's Work Items Meet the Business

SAFe gives us a clear vocabulary for the sizes and scope of work. A Story fits one team in one iteration. A Feature fits one Agile Release Train in one Program Increment. A SAFe Capability, used only when there is a Solution Train, is in SAFe's own words "large solution functionality whose implementation often spans multiple ARTs," still sized to be delivered within a PI. Epics are the large initiatives, owned by the portfolio or local to a Solution Train or an ART.

Stories and features are mainly outputs. They mostly describe what gets built, not what changes for the customer or the business. The business mostly talks one level higher: about an outcome they would name, fund and ask about in a quarterly review.

A note on SAFe terms. In Large Solution and Full SAFe, this level usually takes the shape of a SAFe Capability, which belongs to a Solution Train. Configurations without a Solution Train have no Capabilities: in Portfolio SAFe, epics split straight into features, and in Essential SAFe the business result usually shows up in an ART's PI Objectives.

Where the Teams Sit Today

When we map ARTs with Org Topologies mapping, the teams usually land in the Delivering part of the map, typical for a Delivery Topology. Their skills are fairly complete, and their mandate sits in the outputs half: each owns an application and delivers features into it. The outcome, same-day payout, sits in the upper half of the map. Between the features the teams deliver and the outcome the business wants is a gap that no single team can cross. Product management and the Solution Train roles bridge it by splitting the work and coordinating the pieces, and the program board is where that bridging becomes visible.

The Ferrari Effect: Faster Teams, Same Outcome

Add agents to this picture and the gap stays exactly where it was. The teams get faster at producing outputs, and the outcome is as far away as before.

This is the Ferrari Effect from the book 10X ORG: replace every car in a traffic jam with a Ferrari, and the jam does not move.

Each team is faster on its own, but the work still waits for the other teams, for the program board and for the next PI. More output per team means more work in progress between the teams, and the queues get longer.

Better AI inside the old structure improves the parts. The performance of the whole, the time from an idea to a result the business can see, stays where it was. The constraint sits in the structure between the teams.

Mapping and Assessing Your Own ART

Pick one outcome from your backlog: a SAFe Capability from the Solution Train backlog, an epic in Portfolio SAFe, or a PI Objective with real business value in Essential SAFe. Then:

1. Take an empty Org Topologies map, for example on a whiteboard, and write the outcome in its upper half, where outcomes belong.
2. Find every team that has to change something for that outcome to happen. Place each one on the map: left to right by its scope of skills, bottom to top by its scope of work.
3. Look at the last few outcomes like it. How many sprints, or PIs, did each one take from the first story to a result the business could see?
4. Count how often the work went back and forth between teams on the way: a question, a ticket, a review, a fix, and back again.

The answers show what the current structure costs: how long the business waits for each outcome, and how much effort goes into passing work between teams instead of finishing it. Write them down. They are the baseline for the new org model at the end of this article.

Working Directly on Outcomes

The long road to an outcome and the constant ping-pong between teams both come from the shape of the mandate. No team is allowed to own the result, so the result lives in coordination: in PI Planning, on the program board, in the tickets passed between teams.

Elevation hands the outcome to the people who build it. The back-and-forth then happens inside one unit, in conversation, instead of across team boundaries, and with agents covering more of the specialist work, that unit no longer has to be huge.

The elevated design keeps the people and changes what they are responsible for.

Each person keeps their primary expertise: the risk specialists still know risk, and the finance people still know payments. What changes is how they work: directly with each other on the outcome, instead of through tickets and the program board.

The five teams become one team-of-teams, an elevated ART, which pulls the outcome from a shared backlog and works on it together. Their mandate moves up into the outcomes half.

The agents support the team from below, in the Doing part of the map: narrow skills and task-sized work that fill the gaps, so that the people can stay with the outcome. Feature work still happens, but it no longer defines the teams' identity.

If you want a picture of where this leads, look at the Outcome Agency model, a fluid org model for the agentic age. Driving teams form around customers and their outcomes, overlap where they co-create, and share one product strategy, while supporting teams and agents work around them.

Notice a vital change: a team that owns an outcome is seen as value, not as a cost. A team that can say "we brought payout time from four days to one" has a very different conversation with the business than a team saying "we closed 23 Jira tickets."

How to Start Elevating Your ART

Start with a mapping workshop, not a reorganization. Bring the people from one ART into a room, take two or three real outcomes from the business, and place the teams on the map together. How close is each team to those outcomes? How many handoffs separate them? The picture that comes out is usually more convincing than any slide, because the teams draw it themselves.

Be fair to the structure you find. Application teams, component ownership and features as the unit of work made sense when they were designed. They kept cognitive load manageable and gave every service a clear owner, and in a world where one team could only master so much code, that was a sensible trade. Agentic engineering challenges those constraints. When an agent can carry a good part of the specialist work, a team can take on more of the system, and the old boundaries start to cost more than they protect. The structure is losing its fit, and if nothing changes, the teams drift toward the review work we saw at the start, which is exactly where cost-cutting conversations begin. The honest response is to reimagine the structure and rewire it, one step at a time.

The first step can stay inside the SAFe you already run. Pick one ART whose work a business leader would recognize, and ask for volunteers rather than assigning people. Replace the feature backlogs of the individual teams with one outcome-level backlog for the whole ART: a short, ordered list of results the business cares about, which all its teams pull from. Then move the work closer to an outcome with a new org model, built on one of three elevation patterns:

1. Fluid teams. People from different teams volunteer to work together on one outcome, or a valuable slice of it, and take it end to end as far as they can. For as long as the outcome needs them, they are a new team that is complete for that outcome. Only some people may volunteer, and the others are welcome to stay in their existing teams, or to volunteer for working in this new, fluid way on other outcomes. That way, leaders and team members can compare the old and the new way of working side by side.
2. Leading team. An existing team takes the lead on a whole outcome, even though the outcome needs changes in other teams' applications, not only in its own. To deliver the outcome end to end, the team gets access to the other teams' code and the permission to change it. The other teams share their knowledge and act as guides, not gatekeepers. A joint architecture and design session before implementation helps a lot here: it makes sure the leading team understands the bigger picture, the necessary guardrails and the conventions of the existing software architecture. Later, more teams can join the leading team in its effort, or follow the same model to work on other outcomes in parallel.
3. Team-of-teams. The teams needed for one outcome work as one larger team-of-teams: not in sequence, one after another, but together and at the same time. They refine the outcome together, plan from one shared backlog and decide among themselves each iteration who takes which part, instead of receiving features that were split for them. They integrate continuously and review one result together, so there are no tickets between them, no handoffs and no proxies. The team-of-teams as a whole is accountable for the outcome.

Nothing in SAFe forbids any of these. You keep the PI cadence and the events, and you change which unit owns the work.

Agents make each of these easier than it used to be, because reading and changing unfamiliar code is no longer the wall it was. What remains is mostly a question of permission, and that is an organizational decision. After a few iterations, map the teams again and put the two pictures side by side.

Organizations are still learning how to work with agents. The ones that come out of this period well are likely to use the extra speed to move their people closer to the outcomes, instead of producing more outputs or leaving them to clean up after the agents. A practical first step: pick one outcome before your next PI Planning and map it.

More framework mappings: SAFe →