SAFe Team Topologies: How to Structure Agile Teams for Better ART Performance

SAFe team topologies apply the Team Topologies model, stream-aligned, platform, enabling, and complicated-subsystem teams, to structure an Agile Release Train for fast, low-friction value delivery. Most teams on an ART should be stream-aligned, owning a slice of the value stream end to end. Platform teams provide self-service infrastructure. 

Enabling teams close temporary skill gaps. Complicated-subsystem teams handle work that needs deep, rare specialization. Getting this mix right reduces cognitive load, cuts cross-team dependencies, and directly improves ART flow and predictability.

Key Highlights: The Four SAFe Team Topologies Explained

• Structure, not process, is usually what breaks ART performance: teams built around technology layers instead of value flow create constant dependencies and coordination overhead, no matter how well SAFe ceremonies are run.
• Team Topologies gives SAFe a precise vocabulary for four team types: stream-aligned (owns a value stream end to end), platform (self-service infrastructure), enabling (temporary skill-gap closure), and complicated-subsystem (rare, deep specialization behind a stable interface).
• Two principles drive team design: Conway's Law, which means system architecture mirrors team structure, and cognitive load, which caps how much complexity a team can handle before quality and speed suffer.
• A healthy ART should be 60 to 80 percent stream-aligned teams, translating to roughly 4 to 9 stream-aligned teams in a typical 5 to 12 team ART, with platform, enabling, and complicated-subsystem teams filling the remainder sparingly.
• Interaction modes matter as much as team type: collaboration should be time-boxed and used for discovery, platform teams should operate as self-service (X-as-a-Service), and enabling teams should facilitate temporarily, then step back so the stream-aligned team becomes self-sufficient.
• Common anti-patterns quietly damage ART flow, including enabling teams that never leave, component teams relabeled as platform teams, too few stream-aligned teams, platform teams that turn into ticket queues, and permanent high-bandwidth collaboration that masks unclear ownership.

Most ART performance problems are not process problems. They are structure problems.

A Scrum Master can run a flawless PI Planning event. A Release Train Engineer can enforce every SAFe ceremony to the letter. Yet the train still misses commitments, drowns in dependencies, and burns out its best engineers. The reason is often invisible to the people inside the system: the teams were never designed to work independently in the first place.

This is where team topologies in agile organizations become useful. Team Topologies, the model created by Matthew Skelton and Manuel Pais, gives SAFe practitioners a precise vocabulary and a practical method for deciding how to organize agile teams around flow, not around technology layers or org charts. It complements SAFe's own guidance on team design and gives Release Train Engineers, Agile teams, and Lean Portfolio Management a shared language for structuring an ART that actually performs.

This guide walks through what SAFe team topologies are, how they map to existing SAFe constructs, how to design them for a real ART, and which anti-patterns quietly damage ART throughput. It also explains how team topologies reduce dependencies and cognitive load, which is ultimately what determines whether an ART hits its Program Increment objectives.

The ideas here are not theoretical. They come from patterns observed across hundreds of engineering organizations, and they translate cleanly into SAFe because both frameworks share the same underlying goal: fast, predictable flow of value with the least possible coordination overhead. 

Once you see team design through this lens, many recurring ART problems, missed PI commitments, constant escalations, and unclear ownership, start to look like symptoms of the same root cause rather than a list of unrelated issues.

This article is essentially a practical answer to one question: how to structure an agile release train so that teams spend most of their energy delivering value instead of negotiating handoffs. 

If you are new to the ART construct itself, it helps to first understand what is an agile release train before going deeper into how its internal teams should be shaped.

Why Team Topology Matters for Agile Release Train Performance?

Team topology is not a cosmetic detail. It decides how fast work moves, how many handoffs a feature needs, and how much a team can own without help. A poorly structured ART creates friction at every boundary. A well-structured ART, by contrast, removes friction before it appears.

Two ideas explain why team design in SAFe matters so much: Conway's Law and cognitive load.

Conway's Law and Agile Team Design

Conway's Law states that organizations design systems that mirror their own communication structure. Melvin Conway first described this in 1967, and decades of software delivery evidence have confirmed it. If your teams are split into frontend, backend, and database groups, your architecture will drift toward three tightly coupled layers, no matter what the architecture diagrams say (Wikipedia

For an ART, this has a direct consequence. If teams are structured around technical components instead of the flow of customer value, the resulting system will be equally fragmented. Every feature will need multiple teams to talk to each other, align schedules, and negotiate handoffs. That is precisely the coordination overhead SAFe's PI Planning and ART sync events exist to manage, and precisely what a better team topology can reduce at the source.

The useful corollary is the "reverse Conway maneuver." Instead of letting existing team boundaries dictate a messy architecture, you design the team structure you want first, then let the system architecture follow it. In SAFe terms, this means deciding what your stream-aligned teams should own before you decide who reports to whom.

Cognitive Load and Team Boundaries

The second reason team topology matters is cognitive load. Team Topologies defines cognitive load as the total amount of mental effort required for a team to do its work. This includes:

• Intrinsic load: the inherent complexity of the domain itself
• Extraneous load: complexity added by poor tooling, unclear processes, or unnecessary coordination
• Germane load: the productive effort spent learning and building new capability

A team whose cognitive load exceeds its capacity will slow down, make more mistakes, and struggle to own anything end to end. This is the core design constraint behind every team topology decision. A team boundary should never be drawn wider than what the team can reasonably hold in its collective head.

For SAFe, this is a practical planning input. Before adding scope to a stream-aligned team, before deciding whether a capability needs its own complicated-subsystem team, before deciding how big an ART should be, the cognitive load test should come first. Teams that carry too much cognitive load create ART-level symptoms: missed PI objectives, rising defect rates, and constant escalation to the Release Train Engineer.

This is also why cognitive load and Conway's Law work together rather than separately. Conway's Law explains why a mismatched team structure produces a mismatched architecture. Cognitive load explains why that mismatch feels painful day to day. A team stretched across too many technical layers is fighting both problems at once: an architecture that resists change and a workload that exceeds what any group of people can hold in their heads. 

Fixing one without the other rarely produces lasting improvement, which is why organizing agile teams around both principles together tends to produce far more durable results than addressing symptoms individually.

What Are the 4 Team Topologies?

Team topologies four team types give every team in an organization one of four clear jobs. Skelton and Pais argue that limiting team types to four keeps the model simple enough for both leadership and delivery teams to use consistently.

The four types are:

1. Stream-aligned team
2. Platform team
3. Enabling team
4. Complicated-subsystem team

Each one plays a distinct role, and each one exists, in some way, to support the flow of stream-aligned teams. Understanding these four types is the foundation for everything else in SAFe team topologies.

Stream-Aligned Teams: The Primary Team Type

A stream-aligned team is organized around a continuous flow of work: a single product, a customer journey, a user persona, or a business capability. It owns that stream end to end, from design through delivery, without needing constant handoffs to other teams.

This is the default team type. In a healthy organization, stream-aligned teams should make up the large majority of all teams, roughly 60 to 80 percent according to practitioner guidance. Everything else exists to reduce the burden on these teams.

Inside SAFe, stream-aligned teams map closely to standard Agile Teams. They are cross-functional, typically 5 to 11 people, and carry full ownership of a slice of the value stream. If you want a refresher on what a healthy Agile team looks like at this level, this article on what is a Scrum team in agile is a useful read.

This is also where the older feature teams vs component teams debate connects to Team Topologies. A feature team delivers a complete, end-to-end slice of customer value on its own, which is essentially the same idea as a stream-aligned team. A component team, by contrast, owns a single technical layer, such as a database service or a shared UI library, and depends on other teams to assemble its output into something a customer can actually use. 

SAFe has historically allowed both, but Team Topologies makes the tradeoff explicit: feature teams minimize dependencies and map cleanly to stream-aligned teams, while component teams tend to recreate the coordination overhead that stream-aligned design is meant to remove. A component team is not automatically wrong. It only makes sense when the component genuinely requires deep, rare specialization, in which case it usually belongs to the complicated-subsystem or platform category rather than being just another team competing for space on the ART.

Work sizing follows a related but separate logic. It is worth briefly distinguishing capability vs feature in SAFe, since the two terms describe scope, not team type. A feature is functionality that a single ART can deliver within one Program Increment, and it is what most stream-aligned teams work on sprint to sprint. 

A capability is larger, spans multiple ARTs, and lives at the Large Solution level, only relevant once an organization has grown beyond a single ART. Team topology decisions apply at both scales, but the practical day-to-day impact is greatest at the feature level, where stream-aligned teams either can or cannot deliver something without waiting on another team.

Complicated-Subsystem Teams: When Deep Specialization Is Required

A complicated subsystem team, sometimes written complicated-subsystem team, owns a part of the system that needs specialist knowledge so deep that most engineers cannot reasonably acquire it as a side skill. Think of a pricing engine, a video codec, a cryptography library, or a real-time trade reconciliation system.

The purpose of this team type is narrow and specific: reduce the cognitive load on stream-aligned teams by encapsulating complexity behind a stable, well-documented interface. It is not a home for every difficult piece of code. Team Topologies is explicit that these teams should be used sparingly. If your ART has five complicated-subsystem teams, four of them are probably stream-aligned teams that have been mislabeled.

Enabling Teams: Temporary Capability Transfer

An enabling team is made up of specialists in a domain such as security, test automation, or cloud adoption. Its job is to close a capability gap in stream-aligned teams, then leave.

This is the detail most organizations get wrong. Enabling teams is meant to be temporary. They coach, pair, and transfer skills, not execute the work themselves. If an enabling team becomes a permanent fixture that a stream-aligned team depends on indefinitely, it has quietly turned into either a platform team or a bottleneck.

Platform Teams: Self-Service Infrastructure for Stream-Aligned Teams

A platform team builds and runs the internal services, tooling, and infrastructure that stream-aligned teams consume to reduce their own cognitive load. Examples include CI/CD pipelines, observability tooling, authentication services, and cloud provisioning.

The defining principle here is "platform as a product." A platform team treats other teams as customers. Its success is measured by how often stream-aligned teams choose to use the platform without needing a meeting or a ticket. A platform that requires back-and-forth coordination for every request is not functioning as a platform. It is functioning as a queue.

Team Topologies vs SAFe Team Structures: How Do They Map?

SAFe already has its own vocabulary for team structures: Agile Teams, System Teams, Shared Services, Communities of Practice, and ART-level structures. Team topologies do not replace these constructs. They give you a sharper lens for deciding how each one should behave.

This mapping matters because SAFe was written before Team Topologies became mainstream, so the two vocabularies overlap without being identical. Shared Services in SAFe, for instance, represents specialty roles that support an ART without being dedicated full time, such as a security architect or a UX specialist. Depending on how that role is used, it can behave like a platform team, an enabling team, or occasionally both.

Communities of Practice are informal groups sharing knowledge across an organization. They are not a team topology by themselves, but they often act as the seedbed from which enabling teams form when a skill gap becomes urgent enough to need dedicated attention.

If you want the full picture of how these constructs fit together across all four levels of SAFe, the SAFe big picture is the right reference point.

It also helps to know where team topology decisions sit relative to SAFe configurations explained at the framework level. Essential SAFe, built around a single ART, is where most stream-aligned, platform, enabling, and complicated-subsystem decisions play out day to day. 

Large Solution SAFe adds a Solution Train coordinating multiple ARTs, which is usually where a platform team's scope expands from serving one ART to serving several. Portfolio SAFe layers in Lean Portfolio Management and strategic funding, which is where decisions about permanently staffing a complicated-subsystem team get budget scrutiny. 

Full SAFe combines all of these layers for the largest enterprises. Regardless of configuration, the same four team types and three interaction modes apply. What changes is scale, not the underlying logic.

Are SAFe System Teams the Same as Platform Teams?

Not exactly, though they overlap significantly.

The SAFe System Team is a specialized Agile Team that builds and maintains the Continuous Delivery Pipeline toolchain, supports integration of assets across teams, performs end-to-end solution testing, and helps with release activities. This sounds a great deal like a platform team, because it provides infrastructure that other teams consume.

The difference is scope and interaction mode. A pure platform team, in Team Topologies terms, provides self-service capabilities that stream-aligned teams use without needing direct involvement from the platform team. A System Team frequently does more hands-on work, running end-to-end tests, performing manual integration steps, or coordinating releases directly. That is a more collaborative or even a service-delivery interaction, not the low-touch, self-service X-as-a-Service model that defines a mature platform team.

In practice, many System Teams start as a mix of platforms and enabling responsibilities. As an ART matures its CI/CD tooling and automates more of what the System Team used to do manually, the team naturally drifts toward a cleaner platform-team pattern. The goal is not to rename the System Team. The goal is to evolve its way of working so that stream-aligned teams need it less and less over time.

The 3 Team Interaction Modes and How They Work in SAFe

Team types alone are not enough. Team Topologies also defines three team interaction modes that describe how teams should work with each other at any given moment. Getting the interaction mode wrong is often more damaging than getting the team type wrong.

1. Collaboration Mode During PI Planning and ART Sync

Collaboration mode is high-bandwidth, close, joint working between two teams, usually for a limited period. It is appropriate when both teams have something to learn from each other and the work genuinely requires discovery.

Inside an ART, this shows up naturally during PI Planning and ART Sync events. A stream-aligned team and a complicated-subsystem team might collaborate intensively while designing a new integration point, then step back to a lighter-touch relationship once the interface is defined. Collaboration should always be time-boxed. Left unmanaged, it quietly turns into a permanent dependency that undermines the very autonomy stream-aligned teams are supposed to have.

2. X-as-a-Service for Platform Teams

X-as-a-Service (XaaS) is a low-bandwidth, durable interaction where one team consumes another team's output like an API or a documented service, without needing a conversation every time. This is the default mode for platform teams. A stream-aligned team should be able to read documentation, provision what it needs, and move on.

This is also the interaction mode SAFe implicitly expects from Shared Services and mature System Teams. If a stream-aligned team has to file a ticket and wait days for a platform team to respond, the interaction has degraded into something closer to a traditional service desk than genuine X-as-a-Service.

3. Facilitating Mode for Enabling Teams

Facilitating mode describes an enabling team coaching a stream-aligned team so it can adopt a new practice or technology. It is deliberately time-bound. The point is to leave the stream-aligned team self-sufficient, not permanently dependent on the enabling team.

This mode is the clearest litmus test for whether an enabling team is functioning correctly. If a stream-aligned team still needs the same enabling team's help for the same skill six months later, the facilitation has failed, or the relationship has quietly become a permanent dependency that should be redesigned as a platform service instead.

Worked Example: Designing a 10-Team Agile Release Train Using Team Topologies

Abstract definitions are useful, but a concrete example makes the decision logic clearer. Consider an ART with 10 teams supporting a B2C fintech product: a mobile banking app with card issuance, payments, and fraud detection.

1. Stream-Aligned Teams

Seven of the ten teams are stream-aligned, each mapped to a distinct part of the customer journey:

• Onboarding and KYC team
• Payments and transfers team
• Card management team
• Statements and insights team
• Notifications and engagement team
• Rewards and offers team
• Customer support tooling team

Each team owns its slice end to end, from backend logic to the UI surface the customer sees. None of them need to wait on another team to ship a typical feature.

2. Platform Team

One platform team runs the shared infrastructure: authentication, CI/CD, observability, and the internal API gateway that every stream-aligned team relies on. This team treats the seven stream-aligned teams as customers and measures its success by self-service adoption, not by ticket volume.

3. Enabling Team

One enabling team, focused on secure coding and PCI-DSS compliance practices, rotates through the stream-aligned teams over two PIs. It pairs with each team, runs workshops, and reviews code, then moves to the next team once the skill has taken hold. It does not become the ART's permanent security gatekeeper.

4. Complicated-Subsystem Team

One complicated-subsystem team owns the real-time fraud detection engine. This requires deep expertise in anomaly detection models and regulatory rules that would be wasteful to duplicate across seven stream-aligned teams. It exposes fraud scoring through a simple, well-documented API that the payments and card teams consume without needing to understand the underlying models.

Why Each Team Type Was Selected?

The logic behind this design follows three questions for every team: What does this team need to own to deliver value independently? What would happen if this work stayed inside a stream-aligned team? Does the specialization or infrastructure genuinely repeat across multiple stream-aligned teams?

Fraud detection needed its own team because the specialist skill required (fraud modeling) does not belong inside a payments team's daily cognitive load, and duplicating that skill seven times would be prohibitively expensive. The platform team exists because authentication, deployment, and observability repeat identically across every stream-aligned team. 

The enabling team exists because a compliance skill gap is real but temporary, not permanent. Everything else stayed stream-aligned by default, which is exactly how the model recommends structuring an agile release train: assume stream-aligned first, and justify anything else.

How to Choose the Right Team Topology in SAFe?

The temptation in any organization is to create a new team every time a problem appears. Team Topologies pushes hard against that instinct.

The Cognitive Load Test

Before creating any non-stream-aligned team, ask whether the underlying problem is genuinely a cognitive load issue. If a stream-aligned team is struggling with a piece of work, the first question should be whether that work can be simplified, automated, or absorbed with better tooling, not whether a new team should be spun up to take it over.

A useful heuristic: if two or more stream-aligned teams are independently building the same capability because none of them can absorb it individually, that is a legitimate signal for a platform or complicated-subsystem team. If only one team is struggling, the fix is more often training, tooling, or a smaller scope, not a new team.

4 Questions to Ask Before Creating a Non-Stream-Aligned Team

1. Is this a permanent need or a temporary skill gap? Temporary gaps call for an enabling team, not a new permanent structure.
2. Does this capability genuinely repeat across three or more stream-aligned teams? If not, a platform team is likely overkill.
3. Does this work require rare, deep specialist knowledge that cannot be reasonably distributed? If yes, and only if yes, a complicated-subsystem team may be justified.
4. Can this be solved by better documentation, automation, or a clearer interface instead of a new team? Organizational answers should always be the last resort, not the first.

Running through these questions before every reorg conversation prevents an ART from accumulating teams that exist for historical reasons rather than genuine flow reasons.

How Many Stream-Aligned Teams Should an ART Have?

There is no fixed number, but there is a useful ratio. Practitioner guidance suggests that stream-aligned teams should make up roughly 60 to 80 percent of all teams in a healthy organization, with platform, enabling, and complicated-subsystem teams filling the remainder.

For a standard SAFe ART of 5 to 12 teams, this typically translates to 4 to 9 stream-aligned teams, with one platform team, at most one active enabling team at a time, and zero or one complicated-subsystem team. 

If your ART has more non-stream-aligned teams than that, it is worth investigating whether some of them have quietly become permanent when they should have dissolved, or whether work that belongs inside a stream-aligned team has been carved out unnecessarily.

The ratio should also flex with organizational maturity. A newly launched ART, still finding its architecture, may temporarily need heavier platform investment. A mature ART with a stable, well-documented platform should trend toward fewer platform-team engineers over time as more becomes truly self-service.

Designing Team Topologies When Launching an ART vs Retrofitting an Existing ART

Designing team topology for a brand-new ART is fundamentally easier than retrofitting one, because there is no existing organizational inertia to overcome.

When launching a new ART, start with the value stream map, then apply the reverse Conway maneuver: design the team boundaries you want first, and let the technical architecture follow. Identify the natural "fracture planes" in the domain, the points where work can be cleanly separated without constant cross-team communication, and draw stream-aligned team boundaries along those lines. Add a platform team only once you can clearly name at least three services it would provide from day one. Hold off on enabling and complicated-subsystem teams until a real, evidenced need appears; do not create them speculatively.

Retrofitting an existing ART is harder because teams, code ownership, and reporting lines are already entangled. The recommended approach is incremental. Start by mapping current team boundaries against the four team types and being honest about mismatches. Many organizations discover that what they call a "component team" is actually an unacknowledged complicated-subsystem team, or that a "shared services" group has silently become a permanent enabling team. 

Once the mapping is done, migrate one team at a time rather than attempting a single large reorganization. Extract one platform capability, stabilize it, prove the self-service model works, then extract the next.

Throughout a retrofit, dependency data is your best diagnostic tool. If you want a structured way to trace where an ART's dependencies actually originate before you change team boundaries, this guide on managing dependencies in agile is a strong starting point, since most retrofit decisions should be driven by where dependencies concentrate, not by guesswork.

6 SAFe Team Topology Anti-Patterns to Avoid

Even organizations that understand the model well can drift into these patterns over time. Recognizing them early prevents slow, invisible damage to ART flow.

1. Permanent Enabling Teams

An enabling team that never leaves a stream-aligned team's side is no longer enabling anything. It has become a crutch, and the stream-aligned team has lost the incentive to build the capability itself. If your organization has had the same enabling team assigned to the same stream-aligned team for more than two or three PIs, it is time to either graduate the capability into the team or formally redesign the relationship as a platform service.

2. Component Teams Relabelled as Platform Teams

Renaming a traditional component team, one organized around a technical layer rather than customer value, as a "platform team" does not change its behavior. A genuine platform team treats stream-aligned teams as customers and offers self-service. A relabelled component team usually still requires tickets, meetings, and manual handoffs. The rename creates a false sense of progress while the underlying coordination cost stays exactly the same.

3. Too Few Stream-Aligned Teams

When an ART has more supporting teams than stream-aligned teams, something has gone wrong. This often happens gradually: a platform team grows because "just one more thing" keeps getting added to it, an enabling team never disbands, and a complicated-subsystem team absorbs work that should have stayed distributed. The result is an ART where most of the organizational energy goes into internal coordination rather than customer value.

4. Platform Teams That Become Ticket Queues

A platform team's core promise is self-service. The moment stream-aligned teams need to file a request and wait for the platform team to act on their behalf, the platform has become a bottleneck rather than an accelerator. This is one of the most common and most damaging anti-patterns, because it is often invisible until lead times start climbing across every stream-aligned team simultaneously.

5. Hybrid Team Types With No Clear Purpose

A team that is asked to be part stream-aligned, part platform, and part enabling usually ends up doing none of those roles well. Ambiguous team purpose creates ambiguous cognitive load, which is exactly what the model is designed to prevent. Every team should be able to say clearly which of the four types it is, and if it cannot, that ambiguity is itself the anti-pattern.

6. Excessive Collaboration Between Teams

Collaboration mode is powerful for short, focused discovery work, but it is expensive. Two teams working in permanent, high-bandwidth collaboration mode are effectively one team pretending to be two, with all the coordination overhead and none of the clarity of ownership. If a "temporary" collaboration between two teams has lasted more than a PI or two without a clear plan to move to a lighter interaction mode, it needs review.

How Team Topologies Reduce Dependencies and Cognitive Load Across an ART?

The entire value of applying team topologies in SAFe comes down to two measurable effects: fewer cross-team dependencies and lower cognitive load per team.

Dependencies drop because stream-aligned teams own complete slices of value. A feature that used to require three teams and two handoffs now requires one team and zero handoffs, because the team boundary was drawn around the flow of work rather than around a technical layer. 

Platform teams further reduce dependencies by making common infrastructure available on demand instead of through a shared team's calendar. Complicated-subsystem teams reduce dependencies differently: by encapsulating deep specialization behind a stable interface, so stream-aligned teams depend on a contract, not on a person's availability.

Cognitive load drops because no single team is asked to hold more complexity than it can reasonably manage. Platform teams absorb technical complexity that would otherwise sit on every stream-aligned team's shoulders. Enabling teams temporarily absorbs the learning curve of a new practice so a stream-aligned team does not have to figure it out alone under delivery pressure. Complicated-subsystem teams absorb specialist knowledge that would be wasteful, and often impossible, to replicate everywhere.

Both effects compound at the ART level. Lower dependencies mean fewer surprises during PI Planning and fewer blocked items during execution. Lower cognitive load means teams make fewer mistakes, ship more predictably, and burn out less. This is why team topology decisions, though they might look like an org-design exercise, are directly tied to the metrics an RTE actually cares about: PI predictability, feature throughput, and defect rates.

Understanding these effects fully also depends on understanding the roles that sit around these teams, since a Release Train Engineer, Product Manager, and System Architect all play a part in maintaining healthy team boundaries. For a full picture of who does what, see this guide to understanding roles in SAFe. And because designing and running these teams well is a core skill for anyone facilitating an ART, professionals looking to formalize this expertise often pursue SAFe RTE certification training.

Conclusion

Team structure is not a background detail in SAFe. It is one of the strongest levers an organization has for ART performance, often more powerful than process tuning or tooling investment.

SAFe team topologies give Release Train Engineers, Scrum Masters, and Agile leaders a precise way to answer a question that used to be answered by instinct alone: what should this team actually own, and how should it work with the teams around it? Stream-aligned teams should be the default and the majority. Platform teams should behave like products, not service desks. Enabling teams should be temporary by design. Complicated-subsystem teams should be rare and clearly justified.

None of this replaces SAFe's existing guidance on Agile Teams, Shared Services, or Communities of Practice. It sharpens it. Once you can look at any team on your ART and name its type, its interaction mode, and the specific reason it exists, most day-to-day coordination problems become far easier to diagnose and fix. If you are building or rebuilding an ART, this is worth doing before the next PI Planning, not after the next escalation. For readers looking to put this into practice immediately, this guide on how to build and manage an agile team is a natural next step.