Team topologies

Team Topologies book is a recipe for learning Conway’s law

Interpretation

  1. The team structure is the first draft of architecture. It is always WIP and evolving.
  2. Deliberately minimize Team Cognitive Load on the team. Else they will struggle to achieve mastery. This leads to delays and quality issues which flywheels into decreased Intrinsic Motivation.
  3. The Building block for an org is an empowered & Autonomous team. These groups can be nested for large orgs to create Tribes.

Types of Teams:

  1. Stream Aligned
    1. Primary team, supported by others
    2. Measure: steady flow of features
  2. Enabling Teams
    1. Research, suggest tooling and practices to SA teams
    2. Measure: increase in the relative velocity of the SA.
  3. Complicated Subsystem
    1. Reduce Team Cognitive Load of SA teams.
    2. Measure: High quality of work wrt SA teams
  4. Platform:
    1. Create autonomy for SA teams with the thinnest layer of PAAS
    2. Measure: DORA

Cohesion within teams

Enable cohesion within the teams (cohesion and empowerment separate work groups from teams) * When measuring performance, teams matter more than individuals. Reward Teams, not individuals * Every part of a Software system needs to be owned by exactly one team. The team owns one of * N simple domains * 1 complex domain

Interactions across teams

  • Intermittent collaboration over constant interaction.
  • X-as-a-service, Collaborate on ambiguous interfaces until they are stable. (collaboration is expensive)
  • Consider temporary re-teaming to rekindle empathy.

Need for evolution

  • SW has grown too large for one team
  • Increased lead times
  • Lack of documentation.

❞ Referred In

Team cognitive load
Team Cognitive Load Assessment Based on some of the ideas in the book Team Topologies

📌 Tagged As