Although Team Topologies is strictly not about architecture, it has a huge impact and connection on how we structure team ownership and our architecture according to Conways law. Therefore, I felt this made sense to cover in the Architecture Handbook.
An adaptive model to organization design.
“Team Topologies” is a book that provides a framework for organizing and optimizing software development teams within an organization. The book emphasizes the importance of adapting team structures and interactions to the specific context of the organization and its technological landscape. This is all based on the Reverse Conway Maneuver. By embracing Conways Law, this framework tries to help create efficient teams that will also result in your desired architecture. As always, frameworks come with their fair share of criticism, but it doesn’t make it worth covering and using as input in your decision process.
Team topologies is a framework that gives you the tools, concepts, and patterns that help you reason and navigate the challenges of organizational design, with Conway’s law in view.
Organization not only need to strive for autonomous teams, they also need to continuously think about and evolve themselves in order to deliver value quickly to the customers.
These concepts are used as building blocks on how to reason and think of structuring teams ownership and responsibilities.
Taking Conways Law in consideration, we can use this to our advantage to create teams that result in the architecture/system that we want, while making the teams also more efficient.
Refers to how changes in software and systems are managed and how they flow through an organization’s structure of teams.
The goal of the these team types, is to manage cognitive load for teams by defining clear responsibilities and boundaries.
There are only three ways in which team should interact:
Notice that we recognize the key parts of any generic “system” from Systems Thinking.
Part I (Teams as the means of Delivery) of the Team Topologies Book
- Conway’s law suggest major gains from designing software architecture and team interactions together, since they are similar forces.
- Team Topologies clarifies team purpose and responsibilities, increasing the effectiveness of their interrelationships.
- Team Topologies takes a humanistic approach to building software systems while setting up the organizations for strategic adaptability.
- Organizations are constrained to produce designs that reflect communication paths.
- The design of the organization constrains the “solution search space” limiting possible software designs.
- Requiring everyone to communicate with everyone else is a recipe for a mess.
- Choose Software Architectures that encourage team-scoped flow.
- Limiting communication paths to well-defined team interactions produces modular, decoupled systems.
- The team is the most effective means of software delivery, not individuals.
- Limit the size of multi-team groupings within the organization based on dunbars number.
- Restrict team responsibilities to match te maximum team cognitive load.
- Establish clear boundaries of responsibilities for teams.
- Change the team working environment to help teams succeed.
Part II (Team Topologies that work for flow) of the Team Topologies Book
- Ad hoc or constant changing team design slows down software delivery.
- There is no single definitive team topology but several inadequate topologies for any one organization.
- Technical and cultural maturity, org scale, and engineering discipline are critical aspects when considering which topology to adopt.
- In particular, the feature-team/product-team is powerful but only works with a supportive surrounding environment.
- Splitting a team’s responsibilities can break down silos and empower other teams.
- The 4 fundamental team topologies simplify modern software team interactions.
- Mapping common industry team types to the fundamental topologies sets up organizations for success, removing gray areas of ownership and overloaded/underloaded teams.
- The main topology is (business domain) stream-aligned; all other topologies support this type.
- The other topologies are enabling, complicated-subsystems, and platform.
- The topologies are often “fractal” (self-similar) at large scale: teams of teams.
- Choose software boundaries using the team-first approach.
- Beware of hidden monoliths and coupling in the software-delivery chain.
- Use software boundaries defined by business-domain bounded contexts.
- Consider alternative software boundaries when necessary and suitable.
Part III (Evolving team interactions for innovation and rapid delivery) of the Team Topologies Book
- Choose specific team interaction modes to enhance software delivery.
- Choose between 3 interaction modes - collaboration, X-as-a-Service, and facilitating - to help teams provide and evolve services to other teams.
- Collaboration can be a powerful driver for innovation but can also reduce flow.
- X-as-a-Service can help other teams deliver quickly but only if the boundary is suitable.
- Facilitating helps to avoid cross-team challenges and detects problems.
- Use different team topologies simultaneously for strategic advantage.
- Change team topologies and interactions to accelerate adoption of new approaches.
- Differentiate between explore, exploit, sustain, retire phases using team topologies.
- Expect multiple, simultaneous team topologies to meet different needs.
- Recognize triggers or organizational change.
- Treat operations as high-fidelity sensory input for self-steering.
- Combine a team-first approach with Conway’s law, the 4 fundamental topologies, team interaction modes, topology evolution, and organizational sensing.
- Get Started: begin with the team, identify streams, identify the thinnest viable platform, identify capability gaps, and practice team interactions.
