- Jointly optimizing organization and software architecture is necessary to achieve fast flow.
- Poorly aligned team and software boundaries can result in shared resources, like teams working in the same parts of the code, which causes more expensive and riskier changes.
- Team Topologies is a socio-technical toolkit for organizing teams around independent value streams with fast flow.
- Fast flow should be sustainable, meaning it can be continued over many years. This requires an investment in technical practices and a good engineering culture.
- Teams should generally contain five to nine people to enable a high level of trust and avoid information overload.
- Teams should be long-lived so that they can become experts within their subdomain, contribute new product ideas, and are incentivized to work sustainably and keep code healthy.
- Software developers should not be seen as resources that are partially allocated to multiple streams of work. This has high context switching and doesn’t create conditions for people to do their best work.
- Standardized processes and ways of working stifle teams and prevent continuous improvement.
- Team Topologies encourages a team-first approach, where the team decides who will work on each task and how they will work.
- You build it, you run it is an approach where teams are responsible for supporting their code in production. It can improve flow by reducing handovers and incentivizing teams to build more reliable software.
- Team cognitive load needs to be carefully managed. When cognitive load is too high, a team’s velocity and quality can drop, and there is a risk of burnout.
- Good domain boundaries minimize cognitive load by reducing the scope of a team’s responsibilities to a manageable level.
- Overlaying team boundaries onto a Core Domain Chart can indicate where cognitive load may be too high, like a team responsible for multiple highly complex subdomains.
- There are three types of cognitive load in the model used by Team Topologies:Intrinsic—The inherent difficulty of a taskExtraneous—Additional complexity added by the environmentGermane—The effort to learn a concept
- Conway’s law implies that the communication structures in an organization will influence the design of a software architecture.
- Implications of Conway’s law are ubiquitous, and the concept should always be kept in mind when architecting systems.
- There are four team types in Team Topologies:Stream-aligned teams—Own a stream of work that contributes to the productPlatform groupings—A group of teams owing shared capabilities that empower stream-aligned teams and reduce their cognitive loadComplicated subsystem teams—Own a complex part of the system that requires specialist knowledgeEnabling teams—Support the growth of other teams
- Three interaction modes exist in Team Topologies:Collaborating—Two teams working toward a shared goalX-as-a-service—One team consumes the capabilities of anotherFacilitating—One team helps another
- Collaboration has a high-cognitive load, so it should be applied carefully. More collaboration is not always a good thing.
- The Team Topologies patterns alone will have little benefit if they are not applied in combination with the principles.
- Independent service heuristics is a checklist of heuristics that can be used to assess the leof independence of a candidate or existing value stream.
- There are 10 ISH heuristics covering value, product decisions, dependencies, and more.
- ISH should serve to structure conversation for a diverse group of stakeholders, not as a tick-box exercise for a lone architect-type person.
- John Cutler’s mandate levels consist of a structured model of a team’s autonomy over their work and can be used to assess the independence of a value stream.
- Team Topologies are in a constant state of flux because organizations are always evolving.
- Teams should continually be sensing awkward interactions and signs that the topology should evolve, like excessive collaboration or a reduction in delivery cadence.
- Discover to establish is a pattern that starts with two teams working closely using collaboration mode and then gradually drifting apart to XaaS as boundaries and responsibilities become clearer.
- Dynamic reteaming is a series of principles and patterns documented by Heidi Helfand that concern the fluidity of teams and Team Topologies.
- Dynamic reteaming defines five reasons for reteaming: growth/attrition, new work or priorities, knowledge sharing, stagnation and learning, and surprise reasons.
- There are five patterns for reteaming: grow and split, merging, isolation, switching, and one by one.
- The principles and patterns of Team Topologies and dynamic reteaming also exist at the group level.
- Teams can be grouped into different topologies, such as dedicated frontend and backend teams or groups of teams that are responsible for both the frontend and backend parts of a subdomain.
- Choosing the appropriate grouping of teams involves analyzing the product, domain, organization, and preferences of the people involved.
#Architecture #Modernization #TeamTopologies
