Team Topologies – DevOps beyond technical excellence

Even though the term DevOps (and especially, CI/CD) has been with us for ages, DevOps - as a focus topic - is still a relatively young topic in many organizations.

It has been observed that many companies in the industry use DevOps as a synonym for CI/CD. Not just that, DevOps is still seen in many companies as a purely technical discipline that needs to be mastered, rather than as a holistic concept that spans across the entire software organization.

In my previous article on the subject of DevOps, I had addressed the topic of DORA metrics, exploring how and why we measure our DevOps performance. Today, the focus will be more on what to do if we see little or no progress with technical improvements, or if some KPIs "get stuck" despite correct technical measures and fail to improve.

Even if your DevOps journey has only just begun, you should think right from the start about the measures which you can introduce outside of CI/CD.

For example, companies often introduce DevOps teams to deal centrally with issues relating to the technical implementation of the delivery pipeline or handovers to operations.  

This is a step in the right direction. However, we see that for many organizations, this step is often the last step in the DevOps journey and is only taken when other measures are insufficient.

Instead of relegating this to be the last segment of the DevOps journey, this should actually be the first step in the direction of Team Topologies.  

What are Team Topologies?

The aim of teams is to work on their own deliverables as autonomously as possible. The Team Topologies approach provides a combination of principles and practices that enable a high degree of team autonomy, a high focus on fast-flow software delivery, and high product alignment.  

In a modern DevOps setup, teams should be structured according to value streams - at the core of Team Topologies is the idea of stream aligned teams. Those are teams that are responsible for a requirement from A to Z until delivery, without the need for interaction with or handover to other stream aligned teams.  

Stream-aligned teams are solely and autonomously responsible until go-live or until the software is delivered to the end user- with a few exceptions, as we will see later. The idea of such stream aligned teams is to foster the "You build it, you run it" mindset and nurture the feel of collective responsibility within the whole team.

Advantages – the perks of Team Topologies

Every handover between teams means additional planning effort, additional cognitive load for each team, and often, some waiting time.

For example, team A works on feature X. Suddenly, team A has to wait for team B to finish their work on feature X to be able to continue working on the same feature. In the meantime, team A starts work on feature Y, just to stop again to finish the more urgent feature X once team B is done. These context switches and the added cognitive load should be minimized.

Multiple handovers between teams are often an indicator that responsibilities are not precisely defined and depend on individual people. This means that "small" tasks are often forgotten - feature toggles might not be activated, integration or cross-team integration tests could be neglected, the documentation might be too short, or things could be left in-between responsibilities.

Furthermore, such a setup promotes the formation of knowledge islands across the software delivery life cycle, as individuals take on certain tasks that otherwise no one else feels responsible for.  

Analysis before implementation is made more difficult if teams do not know or understand the entire use case that is being worked on. Development teams are supposed to make complex changes to single components without understanding the overall context.

Especially since remote work has been considered the "new normal" in the IT industry, the pain caused by handovers between teams that do not engage in regular exchanges has become greater and more complicated, and the risk of things getting stuck between teams has increased dramatically due to reduction of hallway communication.

The advantage of largely autonomous teams with overall responsibility in the flow of change is obvious: Handovers between teams are eliminated, the competencies within teams are usually much more clearly defined and even if  knowledge islands arise in individual teams, agile working methods usually ensure that even if individual key players are absent, it is clear which activities need to be done to complete the teams tasks.

Furthermore, teams can ensure during planning that the teams WIP limit matches their own working speed as there is no need to account for downtimes that could happen when waiting for handovers. Also, stream aligned teams can ensure that quality assurance takes place holistically across all levels of the test pyramid and at all relevant points in the delivery pipeline themselves.

Important elements of Team Topologies

In software development, we know of many different types of teams along the software development life cycle. In most organizations, we have at least some forms of development teams, test teams, operations (the “Ops” in DevOps), and infrastructure teams. Additionally, we often encounter various types of support teams (e.g. data maintenance, documentation, etc.), and more.

Team types

Team Topologies comprises four types of dedicated teams:

• Stream-aligned team: Agile teams of usually 5-9 team members like any other agile team. Stream aligned teams should be long living, stable teams with all necessary capabilities to fulfil (almost) any requirement and tackle any obstacle the team faces by themselves including analyzing, developing, testing, releasing, and monitoring the feature that is being developed. The stream aligned team should be optimized for flow of change, so we need to think about minimizing the teams intrinsic and extraneous cognitive load.
• Platform team: The platform team needs to support stream aligned teams in reducing their cognitive load. In Team Topologies the goal is to always aim for the “Thinnest Viable Platform” (so you don’t get bloated platform teams that build solutions that are not really needed). Platforms can be anything from wiki pages on how to use a certain technology to full-blown PaaS solutions that the stream aligned teams can use. This team type should not be responsible or own any part of the  final product that is being developed.
• Complicated subsystem team: Complicated subsystem teams are – as the name already hints at – teams that cover know how for complicated technical solutions that are not part of the daily work of stream-aligned teams. A common example for this kind of team is a complicated subsystem team for an AI subsystem that is being used within the product. It is usually not feasible to have a dedicated AI expert in every stream aligned team, especially if the AI knowledge is only rarely needed for feature delivery. It would be advisable to extract the AI part to a separate team that supports the stream aligned teams, only when needed.
• Enabling team: If stream aligned teams are missing intrinsic knowledge about anything that is required to deliver end-to-end value to the client, an enablement team could be the right answer to aid in building missing know how in the teams. This could be anywhere from enablement in a technical framework or programming language, quality assurance, dev ops or enablement with agile practices and processes.

Interaction modes - Team Topologies knows of 3 ways in which teams can interact:

• Collaboration: Interaction mode between teams for a defined period of time, e.g. a sprint. Usually, the interaction mode between stream aligned teams or stream aligned teams and a complicated subsystem team.
• XaaS: Interaction mode in which something is provided as a service to a team, usually to reduce the extraneous cognitive load or to improve the developing experience. The usual interaction mode for platform or complicated subsystem teams with stream aligned teams.
• Facilitation: A temporary interaction to clear impediments or help the team leap forward in their ability to create value for the end users. Typically, this is the interaction mode for enablement teams.

Team Topologies and remote-first teams

Remote-first is the new normal in IT-companies around the world. Although some companies still try to return to the  “old development world”, it seems that the new working mode, with distributed teams and  colleagues from all over the world, is here to stay.

Gone are the days where you can quickly jump into another team’s room and check how they are implementing their part of a feature and solve minor issues on the fly.  

Without these boundaries of collaborative work, minor issues easily become major annoyances and furthermore, sources for bugs and errors.

Development teams have a full schedule with their daily meetings, retros, plannings, reviews and other on-the-fly coordination, as is anyways. Adding regular meetings with other teams on top of that would be costly and increase the overhead and mental load, so they should remain a rare occurrence between two teams - for example only when two stream aligned teams are collaborating for a sprint – but not every sprint!

With this in mind, we need to think about how we can minimize the need to coordinate between teams and help our teams to work as independently as possible.

Why (else) are we doing this?

In many organizations we can observe that the boundaries of the software system and the developing teams are not aligned with the boundaries of the business domain. New features typically originate from requirements within the business domain and will later be implemented by one or more development teams. If those boundaries don’t match, a high level of coordination between teams is necessary, as every feature will usually need to be implemented by at least two or more teams. With an ever-increasing code base, eventually new features - or even change requests to existing ones - will become more troublesome, time consuming and ultimately expensive.

How to set up stream-aligned teams?

So now we come to the most important question of all - how do we get there? How do we find the miracle solution, the holy grail, the remedy to all our problems?

Before I answer that: What we are striving for is not perfect teams, a panacea to all our troubles when developing, releasing, and maintaining software. What we want to find is a team structure that reflects how customers use the software and on top teams that can build software with an architecture that also fits into this alignment, so that in the end of the day business and development teams speak the same language that is also reflected in the code base.

There is a well-tested way for new or existing projects, to find a good way to model stream aligned teams: Event storming.

Event storming is a workshop-based format to collaboratively explore complex business domains. The idea behind it is to bring software and business domain experts together and model the domains – the well-defined contexts in which only single teams should work in the future – together. In the end the outcome should be exactly what we are looking for: A holistic overview over everything that our software needs to cover, with views on parts of it that correlate to business processes that in the end will be the foundation of our software architecture and our stream aligned teams.

I hope this article has given you new ideas on how you can bring new momentum to your teams. If you are interested in more information on this topic or would like to talk about team setup, team topologies or modern principles in software delivery, I am looking forward to hearing from you!