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

—Matthew Skelton & Manuel Pais

Organizing Agile Teams and ARTs: Team Topologies at Scale

Overview

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

Until now, 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 thinking around team design. Specifically, they provide insights on how to organize solution builders around four fundamental team ‘topologies’: stream-aligned, complicated subsystem, platform, and enabling teams. [1]

Each team type maps to a set of specific behaviors and responsibilities. As noted in the quote above, Skelton and Pais further suggest that these four types are all that is needed, and when taken together, they can dramatically simplify the job of organizational design.

This article describes these team topologies and applies them to Agile teams in the context of SAFe, and then extends them to the organization of ARTs. Doing so provides new and enhanced scaling patterns for organizations developing even the largest and most complex software and cyber-physical systems.

Details

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

1. The value perspective, which is defined by the features it delivers to customers and end users.
2. The technical perspective, which 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 provides a focus for each Agile team, orienting them to the work to be done and limiting their cognitive load to a single concern. In other words, they don’t have to understand everything about the full system; they can 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 has the ability to deliver value directly to the customer or end user.
2. Complicated subsystem team – organized around specific subsystems that require deep specialty skills and expertise.
3. Platform team – organized around the development and support of platforms that provide services to other teams.
4. Enabling team – organized to assist other teams 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 well-formed Agile team. Each is a cross-functional group of 5-11 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, who acts as a servant leader and Agile coach.

Together with this defined team structure, these four team topologies provide a clearer and better model for organizing Agile teams in SAFe. To that end, each team type is described in more detail below, along with their responsibilities and behaviors.

Stream-Aligned Teams

The term ‘stream-aligned’ emphasizes the importance of organizing teams to deliver a continuous ‘stream’ of value 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 hand-offs to other teams to perform parts of the work. [1]

One of the most significant benefits of organizing teams in this way is customer centricity; each team has a direct relationship to the customers they serve. Stream-aligned teams apply design thinking practices to better understand 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.

In SAFe, teams operate within ARTs that fulfill larger development value streams. 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
• Specific steps in the customer journey
• A specific business domain
• Compliance and regulation requirements
• New product innovation

The determining factor is whether the stream-aligned team has the authority and responsibility to build and deliver customer value with minimal dependencies on other teams. This requires that stream-aligned teams be cross-functional and include all the skills necessary to build and support whatever features and components they need. This also ensures that stream-aligned teams are long-lived, developing knowledge developing efficiencies over extended periods of time.

Responsibilities and behaviors of stream-aligned teams

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

• Know your customer – build and maintain direct relationships with customers and develop a deep understanding of the market segments served.
• Develop a steady flow of new features – features describe a customer need and the associated benefits. New features should make up the majority of the work a stream-aligned teams delivers.
• 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 – take responsibility for ensuring 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, incidents, and adjust the course of action.
• Support the solution in production – stream-aligned teams take responsibility for supporting their solution elements in production. In other words, “they build it; they run it.”

Complicated Subsystem Teams

While it is a reasonable ambition is to have primarily stream-aligned teams, it’s unlikely that this will be the only team type required. As solutions become bigger and more 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, to the extent that most team members must be specialists in that area of knowledge in order 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 big 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, 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 (e.g., an engine control module in an autonomous vehicle)

While all solutions can be decomposed into subsystems, not all subsystems 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 – assure quality, performance, and architectural robustness of the subsystem.

Platform Teams

A technology or computing platform is a set of services that the stream-aligned teams can access, typically via a set of 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, which in this case are the stream-aligned teams that utilize them. Customer Centricity and Design Thinking apply in this context also. Additionally, the services they provide should be well documented, easy to use, fit for purpose, ‘thin,’ and offer reuse opportunities.

Responsibilities and behaviors of platform teams include:

• Collaborate with stream-aligned teams – ensure the platforms are developed in line with customer requirements.
• Build the platform incrementally – build and deploy in increments and secure frequent feedback and validation from customers.
• Focus on usability – provide platforms that are easy to use via self-service capabilities and supporting documentation.
• Commit to support 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 are an important 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 … help 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
• Automated testing
• 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. Rather, 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 and then be decommissioned and return 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 wider organization abreast of new technologies and emerging best practices.
• Promote a continuous learning culture – within their own team, the teams they are working with currently, and across the wider organization.

Agile Teams on the ART

In SAFe, teams operate as part of an Agile Release Train (ART). When designing ARTs, and the teams that compose them, it can be useful to visualize these teams in terms of the topologies that they map to. In order to make the team types clear, we use the following icons, shown in Figure 2, to represent the different team types. A stream-aligned team is represented with an arrow on the end, empathizing flow, a square is used to represent a complicated subsystem team, a rectangle for a platform team, and a dotted ellipse for an enabling team.

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 teams on the ART in this manner helps to compare and contrast the merits of competing designs and also provides an indication of how well any particular design is aligned to the flow of value.

Applying Team Topologies at Scale

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 to this is the ‘enabling’ team type. Although it is common to have two or three enabling teams working across the enterprise—all aligned to the same objective—it’s unlikely they would have the scope of an entire ART.)

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

Stream-aligned ARTs

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 full 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 they are 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 means that complicated subsystem ARTs are common when building large-scale systems, again to reduce the cognitive load on the stream-aligned ARTs. For example, a guidance system for an autonomous vehicle could well require an entire complicated subsystem ART.

Platform ARTs

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 example of the autonomous vehicle, 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 also supports a single platform ART that is providing services across multiple development value streams within the organization, as shown in Figure 4 below.

In all these examples, the ARTs are composed of teams that will take on one of the four team types. For instance, within the complicated subsystem ART developing the guidance system may be one or more stream-aligned teams developing the features that relate to environment perception. Similarly, there might be a complicated subsystem team focused specifically 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.

Future advanced topic articles will further explore these themes, one of which will demonstrate how to apply these topologies end to end. Another article will describe how to use these patterns in the architecture of large systems.

Summary

This article brings new patterns to the challenge of organizing Agile teams and ARTs for large-scale system and software development. Applying the four fundamental 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 – A Worked Example

To help illustrate how the four topologies can be applied to identify ARTs and teams, a financial services example will be used. This example consists of two development value streams that together support a consumer banking loans operational value stream, as illustrated in Figure 5. The first development value stream, ‘Loan Application’, focuses on the loan application process and the second development value stream, ‘Core Banking’, focuses on the core banking systems that manage the servicing of the loans.

‘Loan Application’ Development Value Stream

Starting with the loan application development value stream, this includes 340 people so multiple ARTs will be required. One option is to create stream-aligned ARTs around the different channels to market such as online, mobile, branch, etc. Another option is to organize around customer groups such as existing customers, new customers, students, homeowners and so on A third option is to organize around products, which in this case are mortgages, personal loans, auto loans, and loan restructuring.

A decision is taken to go with the third option. Consolidating each product within an individual ART will make them easier to manage and aligns well with the way the organization describes its products and how it measures success. This is in contrast to distributing these products across channels or customer-focused stream-aligned ARTs which would add to the complexity and increase cross-ART dependencies.

Together these stream-aligned ARTs share the responsibility for maintaining and developing the loan application system, without which they would not be able to process loan applications. However, a decision is taken to exclude the credit scoring system from these ARTs. The credit scoring system is designated as a complicated subsystem ART since it requires amongst other things, actuarial expertise, and specialist development skills that are in short supply.

The complete decomposition of the loan application development value stream is as follows, Figure 6.

‘Core Banking’ Development Value Stream

Considering the second development value stream focused on the core banking systems which support the servicing of the loans. After careful consideration, it is decided to create two ARTs.

The first ART is a stream-aligned ART that will develop the specific consumer loans functionality needed to support the operational value stream under consideration, on top of a set of services provided by a second ART which is the core banking platform ART (Figure 7). Indeed, this core banking platform ART provides these services not only for this value stream but also across the wider organization, which is why a dedicated platform ART makes good sense.

Decomposing ARTs into Teams

Once these ART definitions are in place, the next step is to organize the Agile teams within each ART. This typically happens during the prepare for ART launch step of the implementation roadmap. (In this example we will only consider one of the stream-aligned ARTs from the ‘Loan Application’ development value stream as the other stream-aligned ARTs in the same development value stream will follow a similar pattern of decomposition.)

‘Mortgages’ Stream-aligned ART

Considering the team structure for the ‘Mortgages’ stream-aligned ART, four of the stream-aligned decomposition patterns mentioned earlier in the article are applied, as shown in Figure 8 below.

Organizing by customer groups creates three teams: first-time buyers, remortgaging customers, and existing customers. Organizing by steps in the customer journey leads to the creation of stream-aligned teams focused on the online and physical channels. Finally, a compliance and regulation team and a new product innovation team are created. Each of these stream-aligned teams has the ability to deliver real value with minimal dependencies on other teams and when they do need to collaborate it is clear which teams need to work with one another as their responsibilities are well defined.

Alongside these stream-aligned teams, a complicated subsystem team is formed to work specifically on the loan origination system. Although the other teams are capable of interfacing with this system to add and modify the various mortgage products, fundamental changes in the way the system works, although rare, require deep expertise and skills that are in short supply.

‘Credit Scoring’ complicated Subsystem ART

The ‘Credit-scoring’ ART is a complicated subsystem ART and is decomposed into two complicated subsystem teams and one stream-aligned team as shown in figure 9 below.

The first complicated subsystem team is assigned to design the algorithms required by the credit-scoring system to determine the awarding of a loan, and the second is a complicated subsystem team that authorizes exceptions in the loan application process which is required for borderline results. A single stream-aligned team develops the credit-scoring system, working closely with their customers in the other ARTs who need to integrate with this system. (This example helps to illustrate how the topologies are factual in nature – in this case, there is a stream-aligned team within a complicated subsystem ART which recognizes that this team can deliver value independently for the solution they have been tasked with developing.)

Alongside all this development activity, this financial services organization is also investing heavily in their ‘migration to cloud’ initiative. The credit-scoring system is one of the first that has been designated to move to the cloud. In support of this, a ‘cloud technologies’ enabling team will be working with the ‘Credit Scoring’ ART during the upcoming PI.

‘Consumer Loans’ stream-aligned ART

Finally, the ‘Core Banking’ development value stream contains two ARTs, as described above, that need decomposing into teams.

The first ART, which is a stream-aligned ART focused on supporting the consumer banking loans operational value stream is decomposed into four stream-aligned teams grouped around specific steps in the customer journey as well as a complicated subsystem team managing the ‘interest calculation’ component, (Figure 10). This decomposition pattern works well as it aligns to independent streams of value with limited work cutting across multiple teams.

‘Core Banking’ platform ART

The second ART is a cross-value stream platform ART, which includes four platform teams, organized around specific services that stream-aligned teams in the ‘Consumer Loans’ ART will consume (as well as other teams and ARTs across the organization), and four complicated subsystem teams that work on developing the core banking system directly, as shown below in Figure 11.

An additional enabling team supporting automated testing in a mainframe environment will be working with the core banking platform ART for the upcoming PI as part of a continuous delivery initiative that the organization is embarking upon.

Learn More

Last update: 31 August 2021