Drafting Perfect Software Delivery Teams Using Team Topologies

Software developers are scarce as more companies realize that IT is core to their business. Organizations need to be efficient with their developers, empowering them with good architecture and team structure. In this article, I’ll describe what it looks like to create teams that maximize software delivery and operational performance. But first, let’s examine how we got here.

Throughout history, humans have exploited the fact that specialization fosters efficiency. This effect stems from the economy of scale, where one-time investments become insignificant when distributed across large batch sizes. If everybody has to milk cows to supply themselves, no one can afford an entire milking machine. However, if one farm provides milk to thousands of people, they can distribute the price, so each family has to pay 1/1000th of a milking machine.

The mindset of specialization has improved almost every endeavor in history, from farming to server management. Therefore it would reasonably apply to software development. Building on the older sciences of manufacturing and engineering, software development has 5 phases:

1. Analysis — Become experts in the problem
2. Specification — Write down the desired outcome
3. Development — Implement a software system that produces the outcome
4. Testing — Verify that the system does indeed produce the outcome
5. Adoption — Give the system to the target group

Since specialization leads to efficiency, and there are 5 phases, we should probably make five teams staffed with specialists. That way, they can distribute the costs of good tools across software projects, exploiting economy of scale. Our teams would be:

1. Business analysts
2. User experience designers
3. Developers
4. Testers
5. Release managers

Security (and compliance) was not included in the engineering-based view of software development. Probably because relatively few people try to destroy bridges and buildings compared to software. Similarly, maintenance is predictable and marginal in engineering, thus omitted. These and others have been added to software over the years, so now the process (and teams) looks more like this:

1. Business analysts
2. User experience designers
3. Developers
4. Testers
5. Security
6. Release managers
7. Operations

These teams become powerhouses, where all the skills and knowledge are centralized, giving them the name: Centers of excellence.

Apart from an economy of scale, we also get another productivity advantage from this organization: parallelization. If we discover that development is a bottleneck, we can add another development team, doubling the throughput. Alternatively, we can further specialize in subcategories such as frontend and backend.

Example

Let’s look at the organization. Let’s say we’re running an online book store, and have four different problems we’re solving:

1. Browsing our selection
2. Inventory management
3. Price management
4. Recommendations

In this diagram, each box is a team. Arrows on the left are demand, arrows on the right are output, and the arrows throughout are handoffs.

Our four problems go through each center of excellence. Because we have two development teams, we get two deliveries. We’ll come back to this diagram to illustrate the effects of reorganization.

The logic described above builds on more than a century of experience. However, we did make a few implicit assumptions. So, let’s examine some of the side-effects of the decisions above.

Human Factor

When we parallelize, the borders around teams become blurry. It’s hard to see the difference between development teams when they have the same skillset. Therefore, it’s natural that if one team is overloaded and another is underutilized, we can move resources from one to another.

But issues arise when we recognize that programming is not the critical skill of a software developer. Instead, the critical skill is domain knowledge, knowledge of the software they work on every day and its context. Making it clear that humans are not dynamic resources in a knowledge-based industry. Moving a software developer to a different team or moving part of a project to another team essentially forces them to learn a new context from scratch.

Moving developers hurts productivity, not to mention team dynamics and how long-lived teams work together and optimize their workflow—a property we reset when we disrupt the team structure.

Conway’s Law

Another side-effect is that two development teams lead to two products. This effect is known as Conway’s Law, one of the most crucial results in software architecture. It states:

“Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.”— How do Committees Invent, Mel Conway

Discussing all the nuances of this is too much to cover. However, it states that we indirectly expose our (informal) organizational structure through our software. If so, we should organize people in a way that supports our desired architecture. Whoever determines the shapes of our teams are the true architects of our software. Are they skilled to do this if this is an HR department or managers?

The BAPO Model

In an excellent article, Jan Bosch describes a model defining a company in terms of four parts:

•       Business—how are we making money
•       Architecture—how is our software structured
•       Processes—how do we build software
•       Organization—how do we make teams, and how do they communicate.

In the example above, we defined our process and inferred the organization. Doing so automatically locked our architecture due to Conway’s law. Finally, we’re left with business and have hardly any flexibility since the rest is locked in place. If our business fits the market, it’s more luck than strategy.

Instead, we should flip the model. First, assess the market to determine where we think the business is. Based on this, we should define our desired architecture. Again, due to Conway’s law, this gives us the architecture. The processes bridge the architecture and the organization; thus, the bridge follows since we’ve fixed both endpoints.

Learning from the side-effects above, the DevOps movement went directly against the traditional organizational structure. In DevOps, we make teams with both development and operations people. This grew to include silos; teams should have the necessary skills to deliver software independently.

Following this blindly leads to making each team self-reliant, forgoes all advantages of economy of scale. No interaction also means no sharing, and we cannot produce a coherent product. To solve this, Matthew Skelton and Manuel Pais detail in Team Topologies how we should structure our teams and how they should interact. Topology in this context can be thought of as a team type.

First, it establishes that:

The team is the only method of delivery

This rule addresses the human factor. If teams, not individuals, deliver the software, we can’t move people from one team to another. It also sets boundaries to prevent moving projects.

Secondly, team topologies build upon Conway’s law and satisfy the BAPO model by advocating an architecture-before-organization method.

Let’s look at the modern team types and the shortest path from the traditional teams.

Frontend Becomes Stream Aligned

Traditionally the frontend team is closest to the customers, as they are responsible for the interface through which they expose functionality to the users. Frontend teams are dependent on most other teams in a traditional organization: backend, security, UX, testing, etc.

Moving these competencies into the team, we arrive at the most critical team topology responsible for delivering value to customers. DevOps was invented for this type of team, and the properties of pure DevOps teams apply here:

A stream-aligned team should deliver only to external customers. Therefore, they have to be independent of other stream-aligned teams.

We call them stream-aligned because they align with the company’s value stream, i.e., how we make money.

Our running example has four demand-arrows, value streams, and four stream-aligned teams. Business defines architecture, defines the organization. Following this, the diagram looks like this:

Backend Becomes Platform

As mentioned above, we cannot deliver a coherent product if we have only stream-aligned teams because they cannot interact. We need a team to bridge stream-aligned teams. In a traditional model, this may sound exactly like the backend teams. However, backend teams are in a codependent relationship with the frontend teams. Neither can deliver without the other.

Instead, we can achieve this without creating a mutual dependency with the second topology— Platform Teams. Here, the fundamental property is orthogonal to that of stream-aligned teams:

Platform teams only deliver to internal customers.

This formulation allows us to build platforms on top of platforms or share code between multiple stream-aligned teams. It also forces us to separate internal and external requests, which is essential since they are near impossible to prioritize accurately.

Though these teams aren’t directly delivering to customers, they’re still cross-functional, including roles like UX and frontend.

In our running example, we need to deliver a coherent product. Thus, we need a platform team to create a platform on which our stream-aligned teams can implement their products. Building such a platform is complex, so we could need a second platform team to support the first one.

Specialist Becomes Complicated Subsystem

Stream aligned and platform teams cover most of our needs. However, the guideline “just add the competencies to all the teams” is not feasible in some situations; Mainly, when the competency is expensive, this could be AI specialists or tax code experts.

We need a new topology called the complicated subsystem team to remedy this. The fundamental property here is:

Complicated subsystem teams empower expensive competencies.

These teams are purpose-built to ensure that we maximize our value for capital. They must include vital support roles to ensure the most valuable people are never stuck doing comparatively cheap work or are blocked. Therefore they need to be cross-functional.

Complicated subsystem teams expose their functionality much like platform teams: other teams can consume on-demand as a service.

Our recommendation and pricing systems likely need access to GDPR protected data in our running example. These intricate rules must be implemented with great care, requiring expensive developers. Therefore we make a complicated subsystem team to centralize the handling of GDPR.

Specialist Becomes Enabler

While we have now addressed the specialists whose expertise results in software, this is not always the case. These are the specialists who support a transformation. Two common examples include scrum masters and migration experts.

Needs in this category are temporary. Teams need a scrum master while they’re learning. Teams need a migration expert only during the migration. This is the defining property of the final topology:

Enabling teams have no software and are temporary.

This temporary nature doesn’t mean that the people leave the company once the task is completed. Indeed, modern software companies need to be in a constant transformation state, as Mark Swartz discusses in A Seat At The Table. Therefore the team may move on to the next transformation step. Crucially, they must discard their previous responsibility to become a center of excellence.

Because enabling teams are not responsible for any software, they aren’t required to be cross-functional like the other topologies. Instead, this topology favors broad profiles who can quickly seek and acquire information about new tools or processes.

In our example, two teams could be moving from a MySQL database to a NoSQL database. To aid the teams in this effort, we have had an enabling team become experts to assist. It looks like this:

By examining traditional organization structures, we identify three assumptions and their side effects:

• The critical skill is context knowledge, not programming, and moving them incurs a cost.
• Conway’s law states that our organization dictates our architecture.
• The BAPO model tells us that we can’t make strategic business decisions if we start by defining our processes.

Modern organization structures emphasize DevOps teams, which are autonomous and cross-functional. Building on this, we inferred the four basic team topologies:

1. Stream aligned teams—who deliver only to external customers
2. Platform teams—who deliver only to internal customers
3. Complicated subsystem teams—who empower expensive competences
4. Enabling teams—who have no software and are temporary

This model allows us to harness the benefit of economy of scale and avoid undesirable side effects.

Organizational structure is by no means a closed topic. There are already movements towards even more fluid structures across team boundaries, such as Communities of Practice (CoP). If we take this further and let the CoPs own software, it is called Inner Sourcing, where there are essentially no team boundaries, inspired by the open-source communities.

* This is a guest post by Cristian Claussen. You can read more about drafting perfect software delivery teams in Cristian Claussen’s book, Five Lines of Code: How and When to Refactor, making refactoring accessible to everyone. *

Søren Pedersen

Co-founder of Buildingbettersoftware and Agile Leadership Coach