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.