guidance-icon

Organizing Agile Teams and ARTs: Team Topologies at Scale

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

—Mathew Skelton & Manuel Pais

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, Mathew 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):

Figure 1. The four fundamental team topologies
  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 deliver 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 in aligned to the flow of value.

Figure 2. Applying team topologies to Agile teams on an ART

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.

Figure 3. A mixture of topologies applied to ARTs within a Solution Train

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.


Learn More

[1] Mathew Skelton 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: 30 October 2020

 

  

Authors