Self-managed Team of Teams

Description

When an agile team implements self-management well, all the internal planning, coordination and integration is run within the team. This can be very effective and results in highly productive teams that run themselves with little external effort needed. Creating a similar effect at scale but at a multi-team level is essential. The alternative is an external coordination structure required to ensure the teams work properly aligned.

Rationale

Multi-team self-managing can be created by using the product and the product goal as catalysts for the teams. In addition to working for the team’s sprint goal, teams are motivated by the understanding that success is measured on delivering value (“outcome”) for customers, not the team's output.

In the same way that every developer in a team has a shared accountability on the team's output, every developer of every team in a multi-team system has shared accountability on the overall result: they either succeed together or fail together!

Creating high-performing teams of Teams is often not trivial. In a high-performing team, the members are proud of belonging to the Team and often create a strong sense of identity that might create tensions between the Team and other organisational entities (including other teams). In a multi-team scenario, it is essential to balance this “team spirit” and the belonging to a Team with a sense of belonging to the same product development organisation, where the overall purpose is the product to be implemented, rather than the output of a single team.

At scale, these are possible observations indicating the Team of Teams is working in the right way:

• The teams are focused on the overall product rather than on the output of their team
• The actions decided by the teams when coordinating with each other are focused on reaching a common goal rather than optimising at the team level
• In the same way as “there is no I in team”, “there is no single-team in a multi-team”
• Teams are helping each other in all phases of the development
• Teams accept to take on “boring”, “tedious”, … work because “somebody needs to do it” to get the product done
• While teams try to reduce the amount of coordination needed, they ensure coordination happens
• Teams see their customers and end users as the people to work with and for
• Teams are proud of bringing the product to the market

Related Principles

• Self-managed teams - It is often observed how a Team of Teams often "oscillates" between a stronger identity of each Team and a stronger identity of the Team of Teams (and a correspondingly weaker Team identity).