Demystifying Team Topologies in SAFe 

Ideas from Team Topologies have been referenced by the Scaled Agile Framework (SAFe) since version 5.1. Many SAFe classes, including the very popular Leading SAFe, have two slides summarising Team Topologies in the context of SAFe. Personally, I’ve always found a two-slide summary of a 240-page book to be somewhat ambitious - especially in the classroom. I figure I’m not the only one with this observation, so I thought I would attempt my own distillation of the key messages regarding Team Topologies in SAFe. 

For me, an appreciation of Team Topologies starts with an understanding of feature and component teams. In their book Scaling Lean & Agile Development, Larman and Vodde describe a Feature Team as “a long-lived, cross-functional team that completes many end-to-end customer features, one by one.” Feature teams are intended to accelerate flow by minimising handoffs and dependencies. According to Larman and Vodde, this construct has been around since the 1980s! 

The alternatives, which Larman and Vodde warn against, are single-function teams or component teams. Single-function teams only have one function, e.g. design, develop or test. Component teams are cross-functional (e.g., contain design, development, testing, etc.), and they are organised around single technology components. Most experienced agilists advocate for feature teams over single-function or component teams. Team Topologies adds another dimension to this trade-off by bringing the matter of team cognitive load into the equation.

You are probably familiar with the concept of cognitive load on an individual level, i.e. the amount of information a person can hold in their head at any given time. Team Topologies says the same is true of teams; there is a natural limit to the number of responsibilities and domains a team can work across before they are “spread too thin” and delivery suffers. To address this concern, Team Topologies recommends the application of four foundational team types: steam-aligned, enabling, complicated-subsystem and platform teams. 

The Four Fundamental Team Topologies

The principal team shape is the stream-aligned team. These teams are similar to feature teams but can have a broader application than features, such as alignment to a product, a user journey or a persona.  In Team Topologies, a stream-aligned team “is 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.” Stream-aligned teams are customer-facing, enabling fast customer feedback cycles. 

The three other topologies are used to “reduce the burden on the stream-aligned teams”.

• An enabling team provides stream-aligned teams with access to skills or capabilities they don’t have on a “consulting” basis. The System Team and Shared Services are examples of enabling teams in SAFe. This gives stream-aligned teams time to evolve skills/capabilities without taking time away from their primary goal.
• A complicated-subsystem team is similar to a component team but is only applicable when modifying the particular sub-systems requires the expertise of highly skilled specialists who are hard to source and hard to grow. These are more common in the realm of cyber-physical systems, where subsystems are often quite distinct. The other common example is when you have only 2 or 3 people remaining in your organisation who know how to work with a specific legacy technology.
• A platform team is also similar to a component team. Their role is to provide services to the stream-aligned teams, thereby reducing the cognitive load on the stream-aligned teams. One way platform teams differ from complicated subsystems is that the skill sets tend to be much more readily available than in the complicated subsystem teams.  A common example of a platform team is a mainframe team.

When trying to identify the best team topologies for a given Agile Release Train(ART), we start by understanding the range of technologies that the ART is expected to enhance and maintain and the variety of skills the teams need to do this work. Given a maximum team size of nine or ten, including a Scrum Master, a Product Owner and at least one test specialist, this leaves a maximum of six or seven other roles on a team. If you also have more than six or seven technologies requiring unique skill sets, this should trigger a conversation about the make-up of the steam-aligned teams and how they could be best supported by the creation of enabling, complicated-subsystem or platform teams. 

In many cases, even six or seven separate technical skill sets are probably too many for a stream-aligned team. Remember, our goal is to ensure the team's cognitive load is manageable, and that means a team with six of seven single points of failure will be a bad choice. 

The two other big takeaways I had from the Team Topologies book were a reminder to consider Conway’s Law and an introduction to the “three essential team interaction modes” - collaboration, X-as-a-Service, and facilitating. Neither of these topics are included in SAFe’s guidance on Team Topologies, but I thought I would leave these breadcrumbs here for those who are thinking about diving into the book and learning more. Specifically, there is some great guidance on how team structure impacts the architecture of your systems and how to leverage team structure to influence a future architectural state.

While this explanation of Team Topologies as it applies to SAFe is very high-level, I hope it has gone a little way to demystify the topic and make team cognitive load a consideration for your next ART.