Book: Team Topologies - Matthew Skelton & Manuel Pais

([[filing-web/team-topologies-organizing-business-and-technology-teams-for-fast-flow-by-matthew-skelton-goodreads.md|Team Topologies_ Organizing Business and Technology Teams for Fast Flow by Matthew Skelton _ Goodreads]]) Preface PART I TEAMS AS THE MEANS OF DELIVERY Chapter 1: The Problem with Org Charts Chapter 2: Conway’s Law and Why It Matters Chapter 3: Team-First Thinking PART II TEAM TOPOLOGIES THAT WORK FOR FLOW Chapter 4: Static Team Topologies Chapter 5: The Four Fundamental Team Topologies Chapter 6: Choose Team-First Boundaries PART III EVOLVING TEAM INTERACTIONS FOR INNOVATION AND RAPID DELIVERY Chapter 7: Team Interaction Modes Chapter 8: Evolve Team Structures with Organizational Sensing Conclusion: The Next-Generation Digital Operating Model Preface Model: sets of thinking Chapter 1: The Problem with Org Charts Chapter 2: Conway’s Law and Why It Matters Chapter 3: Team-First Thinking (1) Use Small, Long-Lived Teams as the Standard Smaller Size Fosters Trust Work Flows to Long-Lived Teams The Team Owns the Software Team Members Need a Team-First Mindset Embrace Diversity in Teams Reward the Whole Team, Not Individuals (2) Good Boundaries Minimize Cognitive Load Restrict Team Responsibilities to Match Team Cognitive Load Measure the Cognitive Load Using Relative Domain Complexity Limit the Number and Type of Domains per Team Match Software Boundary Size to Team Cognitive Load (3) Design “Team APIs” and Facilitate Team Interactions Define “Team APIs” that Include Code, Documentation, and User Experience Facilitate Team Interactions for Trust, Awareness, and Learning Explicitly Design the Physical and Virtual Environments to Help Team Interactions CASE STUDY: Team-Focused Office Space at CDL Case Study: Stream-Aligned Office Layout for Flow-Based Collaboration at Auto Trader Warning: Engineering Practices Are Foundational Summary: Limit Teams’ Cognitive Load and Facilitate Team Interactions to Go Faster Quote Disbanding high-performing teams is worse than vandalism: it is corporate psychopathy. -- Allan Kelly, Project Myopia Quote the best-performing teams “accomplish remarkable feats not simply because of the individual qualifications of their members but because those members coalesce into a single organism.” (origin: Book: Team of Teams - Stanley McChrystal & Tantum Collins & David Silverman & Chris Fussell) Research by Google who is on the team matters less than the team dynamics when it comes to measuring performance, teams matter more than individuals Model: aspects to consider and nurture: team size, team lifespan, team relationships, and team cognition. (1) Use Small, Long-Lived Teams as the Standard Definition: team a stable grouping of five to nine people who work toward a shared goal as a unit. smallest entity of delivery never assign work to individuals; only to teams. (1.1) Smaller Size Fosters Trust [[model-ideal-team-size-7-2-for-agile-teams.md|Model_ Ideal Team Size - 7+-2 for agile teams]] [[model-dunbars-number-5-15-50-150.md|Model_ Dunbar’s number - 5, 15, 50, 150]] “team-first architecture" the software architecture needs to be realigned with the new team groupings so that teams can continue to own the architecture effectively. (1.2) Work Flows to Long-Lived Teams Typically, a team can take from two weeks to three months or more to become a cohesive unit. [[model-brooks-law-adding-manpower-to-a-late-software-project-makes-it-later.md|Model_ Brooks law - adding manpower to a late software project makes it later]] [[model-tuckmans-performance-model-forming-storming-norming-performing.md|Model_ Tuckman’s Performance Model - forming, storming, norming, performing]] (1.3) The Team Owns the Software continuity of care enables a team to think in multiple “horizons”—from exploration stages to exploitation and execution— [[model-3-future-horizons.md|Model_ 3 future horizons of software development]] Every part of the software system needs to be owned by exactly one team. This means there should be no shared ownership of components, libraries, or code. > a shared library has one team that owns it ownership != keeping ppl away (1.4) Team Members Need a Team-First Mindset For teams to work, team members should put the needs of the team above their own. Behaviors of team first mindset ![[./resources/book-team-topologies-matthew-skelton-manuel-pais.resources/unknown_filename.png]] toxic people even with coaching, some people are - unsuitable to work on teams or - are unwilling to put team needs above their own. Such people can destroy teamwork and, in extreme cases, destroy teams. These people are “team toxic” and need to be removed before damage is done. //todo (1.5) Embrace Diversity in Teams (1.6) Reward the Whole Team, Not Individuals (2) Good Boundaries Minimize Cognitive Load Restrict Team Responsibilities to Match Team Cognitive Load Measure the Cognitive Load Using Relative Domain Complexity Limit the Number and Type of Domains per Team Match Software Boundary Size to Team Cognitive Load (3) Design “Team APIs” and Facilitate Team Interactions Define “Team APIs” that Include Code, Documentation, and User Experience Facilitate Team Interactions for Trust, Awareness, and Learning Explicitly Design the Physical and Virtual Environments to Help Team Interactions CASE STUDY: Team-Focused Office Space at CDL Case Study: Stream-Aligned Office Layout for Flow-Based Collaboration at Auto Trader Warning: Engineering Practices Are Foundational Summary: Limit Teams’ Cognitive Load and Facilitate Team Interactions to Go Faster Chapter 4: Static Team Topologies Chapter 5: The Four Fundamental Team Topologies Chapter 6: Choose Team-First Boundaries Chapter 7: Team Interaction Modes Chapter 8: Evolve Team Structures with Organizational Sensing Conclusion: The Next-Generation Digital Operating Model .

Backlinks