Team Topologies is an approach, which is public available through the same named book by the authors Matthew Skelton und Manuel Pais, published in 2019. It deals with the insight that (software) teams work better together if the type of collaboration is clearly defined.
The approaches from Team Topologies and the P4 Team Flavors are very similar and pursue the same purpose. With both approaches, team structures can be modeled, making them clear, transparent and developable
Team Topologies defines four Team Typs:
- Stream aligned team: In P4 this is the Feature- or Application Team. It creates an application itself or with supplied modules and platforms of the Module/Platform Teams, using the services of the Service Teams. If several such teams are working on the same Application, these are called Feature Teams.
- Enabling team: In P4 this corresponds to the Service-Team. Service Teams are usually teams of experts who make their expertise available, loan their experts to other teams or teams that operate a special infrastructure and use it for providing their services (e.g. test laboratories).
- Complicated subsystem team, is the Module Team in P4. Module Teams are responsible for parts of systems, with a “customer-supplier relationship” with one or more application teams. This ensures that the modules are not an end in themselves, but exist solely to enable good applications.
- Platform team, in P4 also the Platform Team, a special variant of the Module Team. Platform Teams provide complete solution platforms or “system building blocks”, but always with the goal of helping Application Teams build good Applications for end users.
In addition, Team Topologies defines three team collaboration modes:
- X-as service: A team provides a service or delivers something to another team. In P4 this is clearly distinguished. Module and Platform Teams deliver Versioned Modules or Platforms, Service Teams provide a Service.
- Collaboration: The close cooperation of teams.
- Facilitating: A team supports or enables one or more other teams, e.g. through coaching. From a P4 perspective, this overlaps somewhat with the provision of a service (X-as service)
P4 becomes even more concrete with the collaboration models. In principle, the following options are available here:
- A Team receives an artifact as a supply (Knowledge, work results, Samples or Modules)
- A Team receives a service (e.g. an EMC or acoustic measurement)
- A Service/Expert team lends a person to another team for some Iterations (full-time at the Nucleus or part-time as Extended Team Member)
- Two or three teams share Extended Team members
- Two closely cooperating Teams can collaborate in the following ways (e.g. two Feature Teams working on the same Application or two Module Teams working against a complex technical interface)
- They pull their Team Iteration Backlog from the same Team Backlog and may have the same Team Product Owner,
- They have a Joint Team Sync one or more times per week,
- They do the Team Planning, the Team Backlog Refinement, the Team Review and/or the Team Retrospective together.
Conclusion: Team Topologies is an approach worth reading, even if it does not correspond 100% with the P4 approach. Both approaches support the pragmatic values of clarity and transparency.