Team Topologies: Organizing Business and Technology Teams for Fast Flow

by Matthew Skelton

CHAPTER 4 Ad hoc or constantly 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 pattern is powerful but only works with a supportive surrounding environment. Splitting a team’s responsibilities can break down silos and empower other teams. CHAPTER 5 The four 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) 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. CHAPTER 6 Choose software boundaries using a 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.