Developing complex software systems for large enterprises in a truly agile way presents us with challenges on many levels: cultural, organizational, financial, infrastructural, or architectural. In our blog series we look at various problems of scaled agility from a holistic company perspective and try to give practical suggestions for improvement.
Scaled agile development requires many teams working towards a common goal.Â
An optimal team structure minimizes communication and coordination effort and thus shortens the time to market – the length of time between idea and delivery.Â
But is there even an optimal team structure? Unfortunately, the answer is: usually not. But there are building blocks and heuristics that can lead to a significant improvement over an ad-hoc topology, as we have seen in practice.
What Does Up-Scaling Mean for Teams?
Imagine the following case. Working for a midsize insurance company with its own IT developers, we already have introduced agility on team level. We have set up a cross-functional agile team, and it iteratively produces solution increments. But now, a real big software solution is to be built: a global insurance solution. We need more than our one team. Hence, we scale up.
We now have many teams and assign each of them clearly separated sub-tasks, for example different features of the overall solution or sub-areas of an end-to-end process. This might look like an ideal situation as the synchronization effort between our feature teams is significant reduced. However, in our case we are facing a technology stack from frontend to middleware to backend and databases so large that not a single cross-functional 9- or 11-person team in the world can bring together the necessary skills.
Next, we cluster teams into tribes or Agile Release Trains (ARTs) and scale back our aspirations. Only the entirety of the clusters must be cross-functional. But how exactly do we cluster? We remember graph-theoretic cluster optimization.
The task: Find point clouds (team clusters) in space so that the points (teams) with the greatest dependencies and thus the greatest need for communication are in the same cloud or at least in a nearby cloud. The analogy to an office building scenario comes to mind: you should be located in the same room or at least at the same floor with the colleagues you regularly collaborate with to minimize your walking distance across the entire office building. Very well, let us apply an optimization technique to approximate the optimal team topology.
You can already imagine: It is not that easy. For example, we lack data about actual information exchange, its frequency and structure. In addition, it is hard to predict future change in it.
There must be a better way.
Implications of a Poor Team Orchestration
Back to our insurance portal. The team structure follows the three-tier solution architecture and includes teams for frontend, middleware, and backend components. In addition, the (operational) value streams were considered for the “vertical” team cut: For each of the services provided by our portal, a value stream includes all the essential steps that are required from the trigger to the provision of the result. Typical value streams of an insurance company are “sales” for the search, selection, configuration and purchase of an insurance product, or “claims” in the event of an insurance claim.
So far so good.Â
In practice, however, we have found strong dependencies between teams and clusters.Â
Why was that? On the one hand, the value streams were defined, but not always represented by sufficiently delimited modules with defined interfaces. On the other hand, the lack of functional encapsulation of lower layers and the partly monolithic core systems with shared data areas led to further horizontal and cross-layer vertical dependencies.Â
As a result, the synchronization – especially between clusters – was complex and led to waiting times and delays. The “value flow” was slowed down.
Introducing Team Topologies
As we have seen, value-stream orientation alone is not good enough. We also need support from a modular business and system architecture to build an efficient team organization. But how can architecture, value streams and team topology be aligned in practice?
In their book “Team Topologies” Matthew Skelton and Manuel Pais provide a valuable idea. They introduce four standardized and clearly defined types of teams (which we want to call category here) and show that all practical relevant team structures can be set up with these. They also describe typical interaction patterns between the categories. The four team categories are:
- Stream-Aligned Team
The leading team category. Like the above-mentioned feature team, a stream-aligned team is aligned to one or multiple steps of a single, end-to-end value stream. It is easy to adapt to changes and typically implements customer-facing solution features.
- Platform Team
By providing common, generic interfaces (APIs, services) these teams ensure the independence and flexibility of stream-aligned teams. A platform team typically is designed as a more long-term and autonomous organism and includes experienced product management skills.
- Enabling Team
This category can be understood as a generalization of a system or DevOps teams. In contrast to community of practices or chapters it may have a temporary lifetime, in which it continuously improves other teams in three ways:
- transfer knowledge and skills
- remove impediments
- facilitate (DevOps) infrastructure
- Complicated Subsystem Team
This category is dedicated for teams comprising specialized skills for special components (in a given context), e.g., embedded systems, crypto solutions, insurance legacy systems,…
Applying Team Categories
The benefits of these team categories and their interaction patterns (not described in detail here) are obvious: First, they provide a uniform understanding of the skills, needs and behaviour of teams. Second, they allow team structures to be more easily adapted to changing conditions. Above all, however, they are the link between value streams and architecture.
Changes have also been made on the architectural side. The backend was modularized, and the business functionalities were consistently divided into customer-facing components and supporting libraries. The former map the value streams directly, the latter provide shared functionality and regulate communication with the backend.
On this basis, we can now define clusters and implement efficient orchestration. The necessary synchronization and planning events will be lighter than before. Within the clusters (e.g., ARTs) there will only be comparatively few horizontal dependencies that need to be considered, e.g. in the context of “PI Plannings”. Synchronizations and planning can also be dealt with vertically, for example in “Platform Sync” events, possibly at a lower frequency.
Eight Steps to Efficient Team Orchestration
Finally, we combine the above introduced concepts into an easy-to-follow heuristic procedure:
- Use value streams as a principal guideline for vertical partitioning.
- Consider a modular architecture and clear, generic interfaces from day one.
- Define customer-facing business solutions and map them to value stream(s).
- Group business-wise connected solutions to domains.
- Set up stream-aligned, platform teams, and (if necessary) complicated subsystem teams.
- Create enabling teams as needed, particularly in the beginning.
- Only now: group teams within each domain into clusters like ARTs, tribes, etc. as required for cross team coordination.
- Set up orchestration (synchronization and planning) events within clusters (horizontal) and across clusters (vertical).
Conclusion
As a bottom line, we would like you to take the following key points with you:
- Agility does not mean working faster but focusing on value delivery and waiting less through optimized organization and flow. A smart team topology and organizational structure is the key to this goal.
- You need to consider both value streams and a modular architecture from the beginning to set up an efficient team topology.
- The team categories defined by Skelton and Pais provide a great framework to flexibly align team structure with value streams and architecture.
- Organize team clusters (ARTs, tribes) and their related orchestration (planning and synchronization) events last to maximize flow.
- Organize team domains, clusters (ARTs, tribes), and their related orchestration (planning and synchronization) events at the end of the process described above and as lean as possible to maximize flow.
