Team Topologies Summary & Review

A book summary and review of Team Topologies by Matthew Skelton and Manuel Pais

Team Topologies provides deep insight into how Development Teams can achieve high performance. It demonstrates why a team-centric approach is critical to achieving your DevOps and Digital transformation goals.

For anyone leading team(s) or simply working in a team, you’re bound to learn a lot through the case studies and synthetic approach presented. You will acquire a new frame of reference to help your team(s) and organization improve Flow [1]!

Software Architecture & Conway’s Law

Organisations which design systems are constrained to produce designs which are copies of the communication structures of these organisations. - M. Conway [0]

The book starts with a detailed analysis of Conway’s law and how it should inform team organization. The authors demonstrate that system architectures form, live and die with the teams implementing them through their interactions.?

Teams' effective delivery needs a living architecture that sustains Flow [1] and adapts as new features are implemented or when the system needs to scale or change its focus ..?that is an architecture that supports evolution.

Team organization and Software Architecture are interdependent and they evolve in a symbiotic relationship. As a practical example, codescene is a tool that measures how your teams' organization and software architecture are aligned based on code commits.

Team First approach

The authors then analyse what makes teams effective. They review optimal team and group size ( 5 - 9 members in a team, then Dunbar groups of 50, 150, 500 members ). They explain how to engage people and teams through empowerment alongside the dimensions of Autonomy, Mastery, and (shared) Purpose [2].

A fundamental aspect explained is Team Cognitive Load, beyond the sum of team members ability, but a limit to take into account to ensure teams are not overwhelmed by the complexity of the software they own (guidance of one major and two minor systems per team).

Another way to streamline demand on the team is to define a team API in terms of SLA, error budget, documentation, or any other standard way to interact with the team. This includes making independent technology choices as needed?but normally relying on standard tools and processes to make it easy to own part of a software stack.

Finally, a strong argument is made against individual cubicles and open space offices with long rows of desks that actually degrade communication. Instead, office space should foster team effectiveness by letting teams achieve some level of isolation (separate corners, flexible partitions, ..) while enabling cross-team communication and on-demand collaboration. For instance, allow for enough desk space for pair programming/designing and allow for team whiteboards, writable walls, and event space (The authors consider remote work in more detail in this video).

Breaking the Monolith to unleash Flow

At a conceptual level, software architectures should resemble the flows of change they enable [ in business streams] (because a stream flows). - Team Topologies

With a team-first approach as a guiding principle and the need to align teams to your evolving architecture, the authors explain that a loosely coupled architecture based on highly cohesive components that are easy to test together is how teams achieve Flow.?

They analyze in detail how to break monolithic aspects of your system along fracture planes to reach this architecture type. A strong case is made that while there are many ways to split your architecture ( Business Domain Bounded Context, Risk, Change Cadence, Team Location, User Personas, Technology, .. ), they are context-dependent and definitely not equal in achieving Flow.

Microservices are presented as an example of architecture that can decompose well with its independent services, provisioning model and rapid deployment. But the authors warn that Flow is reached only with a Team centric approach that guarantees team ownership of components deployed independently with enforced APIs ( often based on separate data models, storage, and optimistic/resilient consistency ).

Fundamental Team Topologies

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. - Team Topologies

With the argument built so far about autonomous teams, aligned to business streams, and able to flow work as independently as possible, the fundamental team type is not surprisingly a refinement of the ideal Scrum/Agile product/feature team. In fact, the whole book is about enabling these stream-aligned teams to improve flow.

These stream-aligned teams are aligned to value streams and own their codebase and systems, they reduce and optimise their interactions with other teams (great take on Lean Value Streams and Value Stream Mapping [3] ). As one of the practical Tips enriching the book, you are advised to target a ratio between 7 and 10 to 1 between stream-aligned and other teams.

The three other fundamental team types support the stream-aligned teams' ability to flow changes.?

Enabling teams help other teams to improve their capabilities from expertise and tooling to process and practice. The focus of Enabling teams is to grow the other teams and serve their journey towards Autonomy, Mastery, and Purpose [2].?

Complicated sub-system teams should be an exception as they help take care of particularly complex parts of the codebase, components that need the undivided attention of specialists. They help avoid the extreme cognitive tax that these complicated components would levy on stream-aligned teams.?????

Finally, Platform teams deliver platform as a product to the stream-aligned teams, including the definition of pattern and common concepts [4]. They can have more focus on technical aspects but need to embrace product development as their role is to help optimise stream-aligned teams delivery with a strong focus on Developer Experience.

These fundamental team types serve as role models other teams should move towards to optimise delivery. These types scale to the organization level as a self-similar or fractal model where say a platform team decomposes as a set of stream-aligned teams delivering a?platform product itself relying on a lower level platform team.

Note the absence of support or operation teams in the topologies, the analysis on why you don’t need them (while learning about Swarming and Operation as a sensing/sensory mechanism) warrants reading the book on its own.

Team Interaction Modes

Considering how teams should interact is where the book starts to resonate into a powerful toolset to optimise delivery. The figure below shows team interaction modes in action.

The critical argument is that the choice of interaction type needs to be selective and intermittent [5] to streamline delivery. Collaboration (in red) has high (potential) value / high cost whereas X-as-a-Service (chains) provides predictable delivery but limits innovation.?

Facilitating is the last standard interaction mode presented, referring essentially to how Enabling teams support the other teams with well described patterns and anti-patterns.

The figure below shows how collaboration can help define and put in place a Platform-as-a-Service relationship between a stream-aligned team and a platform team, a good way to ensure your platform evolves to purpose and focus on DevEx (Developer Experience).

As Matthew Skelton points out : "A platform is a curated experience for engineers (the customers of the platform). We do not necessarily need to build many (or any) services ourselves for an effective platform.". In fact, with engineer customers, we need to co-evolve the platform (through collaboration between platform and stream-aligned teams or with InnerSource and open access to codebases wherever possible! )

With the added insight that effective interactions are focused and well bounded (supporting coherent subsystem boundaries and APIs), the interdependence between system architecture, teams and their interactions is now fully formed (with a direct link to Domain Driven Design foundations).

How to evolve Team organization

“Disbanding high-performing teams is worse than vandalism: it is corporate psychopathy.” - Alan Kelly, Project Myopia

Beyond building long-lived effective teams whom you move work to, an important point made here is the role of architects in helping shape and evolve team boundaries, interactions, and system architecture in unison.

Another practical tip recommends evolving different team topologies for different parts of the organization at different times to match the team purpose and events ( and avoid just another Re-Org ! ).

The book provides examples of successful changes in the small but the focus is on helping define and evolve a target model through iterative changes: "the most important thing is not the shape of the organisation itself but the decision rules and heuristics used to adapt and change the organisation as new challenges arise; that is, we need to design the design rules, not just the organisation."

Critique

Beyond Teams APIs, Promise Theory [6] is mentioned several times as a way to improve interactions, a dedicated chapter would have been welcome to explain how this approach can be used with Team Topologies and generally how teams can align and share leadership.

Similarly, interaction with Business (teams) is not explained much and references to Inner/Open source are limited. This is a significant gap as the focus existing in Inner/Open source on architecture for participation resonates strongly with many aspects of the book. For instance, an inner-sourced platform seems a good option to increase innovation in parallel to an X-as-a-Service interaction.

Another significant gap in the book is the lack of analysis or reference to common multi teams approaches such as LeSS Requirement Area or SAFe Release Train ( which now use Team Topologies as a Building Block! ). Only the so-called 'Spotify model' Tribes are mentioned with no in-depth analysis on the topology used.

High trust organisations would also have deserved a separate chapter to explain how elements of the book apply to them and where they open up further options to reach the next level of Flow. It feels like the authors stopped at what can work for most organizations without really providing their view on how to evolve to more effective forms of organization.

The role of architects is also not explained in any great depth, we learn having a team of architects is an anti-pattern but it's not clear in which teams architects should be if any .. in all team types in my opinion !

Finally, the authors could help refine a diagram type to represent teams and their interactions, maybe showing Value Streams at the team level (with help from Promise Theory ?). As an example, the team relationships should be directed. Also collaborations with hand-off (say to an Ops team for release) could be shown differently given their Flow impact. It is difficult to imagine representing any complex team topology with more than a few teams with the current modelling.

Conclusion

Team Topologies brings together novel ideas and learnings complementing each other to demonstrate that a Team First approach to software delivery is critical to successful System Architecture and effective Teamwork.

By defining Four Fundamental Team Types and Three Interaction Modes, the book provides a well-thought toolset to build your agile organization and help stream-aligned teams improve delivery.

So start thinking about how you can Stream Align and help realize the full potential of your team(s) and system(s) by taking advantage of Team Topologies!

References

[0] How Do Committees Invent? - Melvin E. Conway

[1] "Flow is a state of optimal performance achieved by applying a clear, consistent, persistent and unified Vision at all levels of an organization." "A flow-based process delivers information on a regular cadence in small batches." "Group flow is what happens when a bunch of people enter the zone together." Flow: Get Everyone Moving in the Right Direction...And Loving It - Ted and Andrew Kallman

[2] Drive: The surprising truth about what motivates us - Dan Pink

[3] Value Stream Mapping - Karen Martin and Mike Osterling

[4] How to build a platform team now! the secrets to successful engineering - Kenichi Shibata

[5] How intermittent breaks in interaction improve collective intelligence - Ethan Bernstein, Jesse Shore, and David Lazer

[6] Thinking in Promises: Designing Systems for Cooperation - Mark Burgess

Resources

• Team Topologies community, industry examples
• Remote-first Team Interactions with Team Topologies video and slides - Matthew Skelton and Manuel Pais
• Remote Team Interactions Workbook - Matthew Skelton and Manuel Pais
• Henny Portman's QRC Card
• Yoan Thirion?Infographic and notes