The restriction to these four team types acts as a powerful template for effective organization design.

—Matthew Skelton & Manuel Pais

アジャイルチームとARTの編成: 大規模なチームトポロジー

---

Note: This article is part of Extended SAFe Guidance and represents official SAFe content that cannot be accessed directly from the Big Picture.

---

概要

SAFe Principle #10 – Organize around value, guides enterprises to organize people and teams around one goal: continuously delivering value to the customer. But to do so, they must consider how best to design their Agile Teams and Agile Release Trains (ARTs). Traditionally, this has been accomplished in various ways: organizing around features, components, sources of funding, even geography, etc. Each approach aims to bring people and cross-functional skills together to enhance flow, the throughput of value, and even the joy of work.

Organizing by Feature and component has been the standard approach for teams and trains within SAFe and Agile more generally.

In their book Team Topologies, Matthew Skelton and Manuel Pais have advanced the practices for team design. Specifically, they provide insights on organizing people around four fundamental ‘team topologies’: stream-aligned, complicated subsystem, platform, and enabling teams. [1] Each team topology has specific behaviors and responsibilities. By restricting team design to the four fundamental team topologies, the organization can use proven patterns to promote flow and deliver value faster.

This article describes these team topologies and applies them to SAFe. Doing so provides new and enhanced scaling patterns for organizations developing even the largest and most complex software and cyber-physical systems.

詳細

For context, any Solution can be thought of from two perspectives:

1. The features define the value perspective it delivers to customers and end users.
2. The technical perspective is how the architectural components of the system interact to implement that functionality.

Organizing teams around features (feature teams) and components (component teams) has been the dominant pattern in Agile. [2] This focuses on each Agile Team, orienting them to work and limiting their cognitive load to a single concern. In other words, they don’t have to understand everything about the entire system, enabling them to focus on the part of the system they are responsible for.

However, this approach is not without challenges. The defining characteristics of a feature team are often unclear and do not always imply end-to-end value delivery. Additionally, the motivations for creating component teams are varied. Optimizations around specific technical expertise and software reuse typically drive those decisions. But this often results in too many teams aligned to specializations and technology, which increases dependencies and inhibits flow.

In their book, Skelton and Pais outline an alternative approach. They describe four types of teams that enhance and simplify the task of organizing around value (Figure 1):

1. Stream-aligned team – organized around the flow of work and can deliver value directly to the customer or end user.
2. The complicated subsystem team is organized around specific subsystems requiring deep specialist skills and expertise.
3. Platform team – organized around developing and supporting platforms that provide services to other teams.
4. Enabling team – organized to assist other groups with specialized capabilities and help them become proficient in new technologies.

No matter how they are organized, Agile Teams are the fundamental building blocks of SAFe, as almost everyone on the ART is part of a team. Each is a cross-functional group of ten or fewer individuals who define, build, test, and deploy an increment of value in a short timebox. The team includes a Product Owner, who leads the definition and prioritization of team backlog, and a Scrum Master/Team Coach, who acts as a servant leader. Together with this defined team structure, these topologies provide a clearer and better model for organizing Agile Teams in SAFe. Each team type and its responsibilities and behaviors are described below. They are designed to improve deployment frequency, team culture, and collaboration across teams and departments.

Stream-Aligned Teams

The term stream-aligned emphasizes the importance of organizing teams to deliver value continuously within the development value stream that builds, runs, and supports the product or solution. Skelton and Pais define a stream-aligned team as follows:

A stream-aligned team is aligned to a single, valuable stream of work, empowered to build and deliver customer or user value as quickly, safely, and independently as possible without requiring handoffs to other teams to perform parts of the work. [1]

One of the most significant benefits of organizing teams this way is Customer Centricity. Each team has a direct relationship with the customers they serve. Stream-aligned teams apply Design Thinking practices to understand better the personas representing the customer segments they serve—building and supporting their desired features. It stands to reason that most teams in a Lean-Agile enterprise should be stream-aligned.

Rarely can a single stream-aligned team build an entire solution. More commonly, stream-aligned teams support a portion of the development value stream aligned to one of the following aspects:

• A specific solution or solution subset
• A set of features
• A specific customer persona
• A customer journey or particular steps in the journey
• A specific business domain
• Compliance and regulation requirements
• New product innovation

The determining factor is whether the stream-aligned team is responsible for building and delivering customer value with minimal dependencies on other teams. This requires that stream-aligned teams be cross-functional and include all the skills necessary to develop and support whatever features and components they need. This also ensures that stream-aligned teams are long-lived, developing knowledge and creating efficiencies over extended periods.

Skelton and Pais define a set of expected behaviors for each team type. Within the context of SAFe, we interpret these responsibilities for stream-aligned teams as follows:

• Know your customer – build and maintain direct customer relationships and develop a deep understanding of the market segments served.
• Develop a steady flow of new features describing a customer’s need and the associated benefits. New features should make up most of the work stream-aligned teams deliver.
• Apply Design Thinking – understand the problem space, explore solution options, validate with customers, and incorporate feedback.
• Apply continuous improvement practices – reserve capacity for improving the processes and tools needed to do the work.
• Build in quality – ensure all work meets appropriate quality standards throughout development.
• Collaborate – identify and manage collaborations with other teams on the ART and shared services.
• Respond to customer needs – react to new feature requests and incidents and adjust the course of action.
• Support the solution in production – stream-aligned teams take responsibility for supporting their solution elements. In other words, “they build it, they run it.”

Complicated Subsystem Teams

While it is reasonable to have primarily stream-aligned teams, it’s unlikely that this will be the only team type required. As solutions become more extensive and complex—often including a mix of hardware and software components—they will likely include subsystems. Building and operating some of these subsystems requires specialist knowledge and expertise. Skelton and Pais acknowledge this by defining the purpose of a complicated subsystem team:

A complicated-subsystem team is responsible for building and maintaining a part of the system that depends heavily on specialist knowledge. Most team members must be specialists in that area of expertise to understand and make changes to the subsystem. [1]

Requiring stream-aligned teams to gain and maintain the requisite skills to the necessary proficiency levels across all potential subsystems would create too much cognitive load. The teams can become overwhelmed by the complexity, unable to focus on a domain they can truly master. Instead, complicated subsystem teams pick up a significant portion of that load, taking responsibility for building and maintaining those parts of the system that require deep and ongoing technical expertise.

A complicated subsystem team could build things such as:

• Highly specialized system components are often used across multiple systems
• Safety-critical systems elements, which have a high cost of failure
• Specialty algorithms or business rules that are critical for fitness of use in the domain
• A part of a cyber-physical system (for example, an engine control module in an autonomous vehicle)

While all solutions can be decomposed into subsystems, not all require complicated subsystem teams. The level of expertise, complexity, and risk should be the only deciding factors for creating complicated subsystem teams.

This contrasts with traditional component teams, which may be justified for other good reasons, such as reuse or architectural integrity. As a rough guide, a single ART should contain no more than 1-3 complicated subsystem teams.

The responsibilities and behaviors of complicated subsystem teams include:

• Build, maintain, and support the complicated subsystem – recognize and commit to the critical technical elements they build.
• Maintain their level of expertise – continue to advance the knowledge and skills required to work within that subsystem domain.
• Collaborate with stream-aligned teams – ensure the subsystems are developed to meet customer requirements.
• Plan and prioritize effectively – align the subsystem roadmap with the needs of the stream-aligned teams.
• Develop appropriate interfaces – hide the complicated nature of the subsystems behind well-documented, easy-to-use interfaces.
• Takes responsibility for built-in quality – ensures the subsystem’s quality, performance, and architectural robustness.

Platform Teams

A technology or computing platform is a set of services stream-aligned teams can access, typically via self-service APIs. Much like the complicated subsystem teams, platform teams (and the platforms they maintain) are created to reduce a stream-aligned team’s cognitive load. Moreover, they should be allocated in a way that increases the autonomy of the stream-aligned teams. Platform teams are defined as follows:

Platform team[s] provide the underlying internal services required by stream-aligned teams to deliver higher-level services or functionalities, thus reducing their cognitive load. [1]

This focus on platform teams as’ service providers’ heavily influences the way they work. Platforms are treated as ‘products’ developed for their customers, the stream-aligned teams that utilize them. Customer centricity and design thinking apply in this context also. Additionally, their services should be well documented, easy to use, fit for purpose, narrow in scope, and offer reuse opportunities.

Responsibilities and behaviors of platform teams include:

• Collaborate with stream-aligned teams – ensure the platforms are developed per customer requirements.
• Build the platform incrementally – build and deploy in increments and secure frequent customer feedback and validation.
• Focus on usability – provide platforms that are easy to use via self-service capabilities and supporting documentation.
• Commit to supporting and maintenance – ensure the platform’s sustainability and uptime, and commit to appropriate service-level agreements.
• Lead by example – keep the platforms’ thin and develop them on top of other platforms where applicable.

Enabling Teams

The tools and techniques for solution development are constantly changing, providing organizations with regular opportunities to integrate new practices and technologies. Although this brings many benefits, it also represents challenges to developing the necessary skills and expertise across all the teams. Enabling teams is an essential construct. They can provide support and guidance to other teams, assisting them in gaining these new skills and getting up to speed with these emerging technologies. Enabling teams are defined as follows:

Enabling teams helps stream-aligned teams acquire missing capabilities, usually around a specific technical or product management area. [1]

One example of an enabling team in SAFe is the System Team, which assists ART teams with (among other things) building and supporting the Continuous Delivery Pipeline. Some more specialized examples of enabling teams might provide expertise and support in the following areas:

• DevOps implementation
• 自動テスト
• Continuous integration and build tooling
• Engineering quality practices
• Security
• Environments and configuration

Enabling teams may also be focused on helping stream-aligned teams the first few times they need to integrate with a specific subsystem or platform. However, enabling teams are not there to fix quality issues caused by stream-aligned teams. Instead, they work with them for short periods, typically for a PI or so, to increase their skills and embed the required capabilities.

Depending on their charter, enabling teams may be persistent and move to support another team, ART, or part of the organization. Or, they may be created for a specific purpose, decommissioned, and returned to their regular work.

Responsibilities and behaviors of enabling teams include:

• Innovative – identify opportunities for improvement, including adopting new technologies and practices.
• Collaborate proactively – identify the teams they need to work with, understand their specific requirements, and check progress regularly.
• Communicate regularly – keep the teams and the broader organization abreast of new technologies and emerging best practices.
• Promote a continuous learning culture – within their team, the teams they are working with currently, and across the broader organization.

Agile Teams on the ART

In SAFe, teams operate as part of an Agile Release Train (ART). When designing ARTs and the teams composing them, it can be helpful to visualize them considering team topologies. To clarify the team types, we use the icons in Figure 2 to represent them.

These icons can also be used to visualize the likely interactions between the teams through their relative positioning. The names of the specific teams can then be added to these icons for a complete picture. Visualizing the ART’s teams helps to compare and contrast the merits of competing designs and indicates how well any particular design is aligned with the flow of value.

So far, we have discussed how team topologies can help design the teams that make up ARTs. But many enterprises also need to organize ARTs that form part of larger Solution Trains. Fortunately, these topologies can be readily extended to help make the right trade-offs in ART design (Figure 3).

---

Note: A general exception is the ‘enabling’ team type. Although it is common to have two or three enabling teams working across the enterprise aligned to the same objective, they would unlikely have the scope of an entire ART.

---

Scaling these topologies to organize ARTs requires additional considerations, as highlighted in the sections below.

Stream-aligned ART

A stream-aligned ART, just like a stream-aligned team, will have the necessary personnel, skills, and authority to deliver value, whether it’s a complete product, service, subsystem, or whatever portion of the solution they have been tasked with.

The areas of responsibility for these stream-aligned ARTs are generally the same as those for stream-aligned teams. And the same options for aligning them around a particular aspect, as covered earlier, apply here as well.

Complicated subsystem ART

Most large systems also include extensive subsystems. This meant complicated subsystem ARTs are expected when building large-scale systems to reduce the cognitive load on the stream-aligned ARTs. For example, an autonomous vehicle’s guidance system could require an entire complicated subsystem ART.

Platform ART

Similarly, it’s common for a Solution Train to have Platform ARTs providing services that the stream-aligned ARTs extend and build on. Continuing the autonomous vehicle example, a communication system that manages data transferred between the various subsystems would likely be represented as a platform ART with clearly defined interfaces.

One additional benefit of the platform topology is that it supports a single platform ART that provides services across multiple development value streams within the organization, as shown in Figure 4 below.

The ARTs comprise teams that will take on one of the four-team types in all these examples. For instance, the complicated subsystem ART developing the guidance system may contain one or more stream-aligned teams developing the features related to environment perception. Similarly, a complicated subsystem team might focus explicitly on routing algorithms. In this manner, the application of the topologies is fractal.

Of course, there is an intermediate pattern where, within a single ART, there may be a collection of teams working on the same platform or complicated subsystem. In this instance, the work must be carefully allocated to minimize handoffs and dependencies.

Enabling ART

While not pictured in Figure 3 and less common than the other ART topologies, enabling ARTs provide specialty tools, services, or expertise to other ARTs and teams. Some enabling ARTs may operate as part of a solution Solution Train, internally enable the other ARTs delivery or externally enabling consumers of the Solution Train’s large solution.

まとめ

This article brings new patterns to organizing Agile teams and ARTs for large-scale system and software development. Applying the four basic topologies can simplify this complex problem.

Of course, this all relates to the need to continuously reflect on whether our current organizational models serve us well. Thus, organizations must continually Inspect and Adapt (I&A) and, as necessary, reorganize to follow the value driving the market. Organizational Agility demands nothing less.

---

Appendix: Team Topologies at Scale Example

To illustrate how team topologies can be applied to ARTs and Agile Teams, a financial services example for ABC Bank is provided in this appendix. Specifically, this example will focus on Retail Loans.

ABC Bank has created two Development Value Streams (DVS), which collaborate to support the Retail Loans Operational Value Stream (OVS) shown in Figure 5.

1. Retail Loans DVS – focuses on developing solutions for the origination of retail loans, such as mortgages, personal loans, auto loans, and more.
2. Core Banking DVS – focuses on developing solutions for servicing retail loans and provides other solutions (such as commercial banking, business loans, and investment banking) not described in this example.

Retail Loans DVS

The Retail Loans DVS in Figure 6 includes 340 people (80 in the US, 230 in India, and 30 in Estonia), requiring multiple ARTs. Three options are considered for defining the ART’s teams:

1. Organize ARTs around channels: online, mobile, and bank branches
2. Organize ARTs around customer segments: existing customers, new customers, students, and homeowners
3. Organize ARTs around loan products: mortgages, personal loans, auto loans, and more.

After analyzing the choices, option three is chosen. Each loan product will be an ART within the Retail Loans DVS (as part of a Solution Train), as shown below.

Each ART will serve all customer channels and segments. It’s hypothesized that the proposed ART definition will reduce complexity and the number of dependencies, making value flow with less interruption. Another benefit is that this design better aligns with how the bank describes its products and measures business results.

The credit scoring subsystem requires highly complex algorithms and artificial intelligence. It requires specialized knowledge and development skills, which are in short supply. After reviewing the design, a decision is made to reduce the cognitive load on the other ARTs in this DVS by making the credit scoring system a complicated subsystem ART. The benefit of this decision is that the specialist will not be distributed across the three ARTs, increasing the credit scoring subsystem’s architectural integrity, especially since AI was recently added to the solution.

The complete decomposition of the Retail Loans DVS is shown in Figure 6.

Core Banking DVS

The Core Banking DVS (Figure 7) serves many bank areas besides retail loans, such as commercial loans, investment banking, and more, not shown here. After careful consideration, two ARTs will be created for this DVS:

1. Core Banking Platform ART – provides core banking services for this value stream and others across the broader organization, which is why a dedicated platform ART makes sense.
2. Retail Loans Stream Aligned ART – develops the retail loans functionality needed to support the Retail Loan OVS.

Organizing Agile Teams within ARTs

The next step is to organize the Agile Teams within each ART illustrated in Figure 8. To simplify the example, we will only decompose one stream-aligned ART (mortgages) for the Retail Loans DVS. The other two stream-aligned ARTs (personal, auto) will use a similar team topology pattern, which is not shown here for simplicity.

Mortgages Stream-Aligned ART

Considering the team structure for the Mortgages stream-aligned ART, the team topologies mentioned earlier in the article are applied, as shown in Figure 8 below.

1. It’s decided that three stream-aligned teams will focus on different customer segments: remortgaging, first-time buyers, and existing customers.
2. Another two stream-aligned teams were formed to manage customer channels: online channels (for example, web, mobile) and physical channels (for example, bank branches).
3. Finally, two additional stream-aligned teams were formed for internal business processes: compliance and new product innovation.

These stream-aligned teams can deliver value with minimal dependencies on other teams. When they need to collaborate, it’s clear which teams must work together as their responsibilities are now well defined.

A loan origination, complicated subsystem team is also formed. Although other teams are capable of interfacing with it via APIs to add and modify the various loan products, it requires deep loan origination knowledge and C programming language skills that are in short supply.

Credit Scoring Complicated Subsystem ART

The credit-scoring complicated subsystem ART is decomposed into four teams, as shown in Figure 9 below.

It consists of a stream-aligned team, two complicated subsystem teams, and an enabling team:

1. Credit scoring System (stream-aligned) – This team works closely with two other complicated subsystem ARTs that must integrate with this system. This example illustrates how the topologies are flexible. In this case, a stream-aligned team within a complicated subsystem ART recognizes that this team can deliver value independently for retail loans.
2. Credit Scoring Algorithm (complicated subsystem) – designs and maintains highly complex credit scoring algorithms for retail loans.
3. Credit Scoring Exceptions (complicated subsystem) – creates functionality that authorizes exceptions in the loan application process.
4. Cloud Technology (enabling team) – Alongside all this development activity, Retail Loans invests heavily in migrating to the cloud. The credit-scoring complicated subsystem is one of the first systems designated to move to the cloud. In support of this, an enabling team will help all teams in this ART migrate to the cloud during the upcoming PI.

The personal and auto loans stream-aligned ARTs must also be decomposed into teams for the Retail Loans DVS (not shown here to keep the example simple).

Finally, the Core Banking DVS contains two ARTs described earlier in Figure 7 that needs decomposing into teams and is described in the following sections.

Core Banking Platform ART

The first is a Core Banking Platform ART (Figure 10), which is comprised of four platform teams, four complicated subsystem teams, and an enabling team:

Figure 10. Team structure for the core banking platform ART

1. Four platform teams are formed for different parts of the customer journey: new account creation, account closure, and payment processing (two Agile Teams)
2. Four complicated subsystem teams are formed for shared Core Banking components that are highly complex.
3. An enabling team that supports automated testing will help the core banking platform ART’s teams in the upcoming PI as part of the organization’s continuous delivery improvement initiative.

Retail Loans Stream-Aligned ART

The second ART in the Core Banking DVS is stream-aligned and focuses on supporting the Retail Loans OVS (Figure 11).

1. The Customer Loans stream-aligned ART is decomposed into four stream-aligned teams for specific steps in the customer journey: loan default, loan servicing, new loan creation, and loan payments.
2. A complicated subsystem team calculates the loan interest.

The decomposition pattern for this ART works well, allowing teams to deliver value independently and together with limited dependencies.

---

詳しく学ぶ

[1] Skelton, Matthew, and Manuel Pais. Team Topologies: Organizing Business and Technology Teams for Fast Flow. IT Revolution Press, 2019.

[2] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

Last update: 17 April 2023