This problem goes away if we reduce the number of team types to four basic team topologies.
· Mobile team
· Empower the team
· Complex subsystem team
· Platform team
When used correctly, these four team topologies meet the needs of building and operating modern software systems. combine
Effective software boundaries (Chapter 6) and team interaction patterns (Chapter 7), four types of teams that can become effective
A tool for organizational design
1) Liquid team
Fluid teams correspond to a single, valuable workflow, which may be a product, a service, a
A set of features, a user story, or a set of personas. Furthermore, the team has the ability to quickly,
Safely and independently build and deliver user value without handing off parts of the work to other teams
2) Empower the team
The empowerment team should try not to let itself become an "ivory tower" of knowledge and interfere with the technical selection of other teams.
Instead, help teams understand and follow organizational technical constraints. This is also known as "servant leadership," but
It applies to team interactions rather than individual interactions. The mission of Empowering Teams is to empower fluid teams to
Increase its autonomy, so it needs to focus on solving problems encountered by mobile teams, rather than promoting their own solutions
solution. If the enabling team does a good job, the team they help should be able to independently
Instantly run, rather than always rely on yourself.
What behaviors and outputs should a high-performance empowerment team have?
· The empowerment team should actively understand the needs of the mobile team, and establish regular checkpoints and joint communication during in-depth collaboration
communication mechanism.
· The empowerment team should stay on top of the wave in their professional field, before the actual demand is raised by the fluid team,
Ongoing follow-up on new methods, tools and practices. In the past, this was often seen as the mission of architects or innovation teams,
But it would be even better if we can achieve this goal by empowering other teams.
· Enabling teams to both spread good news (eg, “Here’s a new UI automation testing framework that
Our test script code has been reduced by 50%"), nor can bad news be glossed over (for example, "Our current widely used
JavaScript framework is no longer maintained”). This allows specific technologies to be introduced when appropriate and
Discard them when appropriate.
· In some cases, when it is difficult for the mobile team to use certain services directly, the enabling team should act as an internal and external
service agent.
· An empowered team should not only promote learning within its own team, but also act as an organizational facilitator between fluid teams
The role of sharing the necessary knowledge (this is also the "key learning ability" mentioned by Tom DeMarco and Tim Lister).
3) Complex subsystem team
The complex subsystem team is responsible for building and maintaining subsystems of the system that rely heavily on domain expertise. corresponding
Naturally, most team members must be experts in the field in order to understand and change the subsystem.
The goal of this team is to reduce the awareness of fluid teams in systems that contain or use complex subsystems
load. Complex and specialized jobs require specialists with specific competencies, which are often difficult to develop or find
try to find. We cannot have experts in every fluid team that uses complex subsystems, which is difficult
Now, because the cost is too high and it does not match the goals of the fluid team.
Here are some examples of complex subsystems: video encoding and decoding, some kind of mathematical model, real-time transaction conflicts
Solving algorithms, business reporting systems for financial services, face recognition engines, etc.
What behaviors and outputs should a high-performance complex subsystem team have?
· The complex subsystem team organizes work according to the current stage of development of the subsystem: early design and
In the development stage, work closely with fluid teams; in the later stage when the subsystem stabilizes, reduce interaction and focus on
Focus on the evolution and use of subsystem interfaces, features.
· When assisted by a complex subsystem team, the delivery speed and quality of the subsystem are significantly higher than when only fluid
The situation when the team is in charge (before the decision to split).
· Complex subsystem teams need to be organized according to the needs of the fluid teams that use these complex subsystems
Prioritize and complete delivery.
4) Platform team
As we can see, the mission of the platform team is to provide low-level internal services for mobile teams to facilitate mobility
Reduce the cognitive load on fluid teams by enabling them to deliver advanced services or functionality.
What behaviors and outputs should a high-performance platform team have?
· The platform team works closely with the fluid team and understands the needs of the fluid team.
· Platform teams rely on rapid prototyping techniques, bringing in fluid team members early for quick feedback, which
What works and what doesn't.
· The platform team needs to focus on the availability and reliability of the service and treat the platform as a product that needs to be defined
Regularly return to users to confirm the availability of the service and whether the service still meets the needs of users.
· Platform teams should themselves be users of the services they provide (if applicable), as mobile teams
Fight side by side with the enabling team, and if possible, rely on the underlying platforms that other platform teams are responsible for.
· The platform team should understand that the new internal services it provides (e.g. new technology) will be flowed by each flow like an innovation curve
Dynamic teams are introduced gradually, not overnight.