More on this book
Community
Kindle Notes & Highlights
Read between
August 11 - December 7, 2024
In Making Work Visible, Dominica DeGrandis recommends the use of a Physical Dependency Matrix or “dependency tags” on kanban cards to identify and track dependencies, and infer the communication needed to make these dependencies work well: “Visualizing important cross-team information helps communicate across teams.”
The architecture of the system gets cemented in the forms of the teams that develop it. —Ruth Malan, “Conway’s Law”
In the book Accelerate, Forsgren, Humble, and Kim tell us that high-performing teams are continuously improving their capabilities in order to stay ahead.
Stream-aligned teams are also under constant pressure to deliver and respond to change quickly.
An enabling team is composed of specialists in a given technical (or product) domain, and they help bridge this capability gap.
Enabling teams have a strongly collaborative nature; they thrive to understand the problems and shortcomings of stream-aligned teams in order to provide effective guidance. Jutta Eckstein calls them “Technical Consulting Teams,”
Use these heuristics from Robert Greenleaf to guide the behavior and drive of the enabling team: “Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous?”
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced coordination.
As Forsgren, Humble, and Kim put it in Accelerate, “Architects should collaborate closely with their users—the engineers who build and operate the systems through which the organization achieves its mission—to help them achieve better outcomes and provide them the tools and technologies that will enable these outcomes.”
When code doesn’t work . . . the problem starts in how teams are organized and [how] people interact. —Eric Evans, Domain-Driven Design
The research published in Accelerate demonstrates that tightly coupled architectures negatively influence the capacity of having autonomous teams with clear responsibilities.
“Architectural approaches that enable this strategy [of supporting teams’ full ownership from design through to deployment] include the use of bounded contexts and APIs as a way to decouple large domains into smaller, more loosely coupled units.”
“If you have microservices but you wait and do end-to-end testing of a combination of them before a release, what you have is a distributed monolith.”
Technologies and organizations should be redesigned to intermittently isolate people from each other’s work for best collective performance in solving complex problems. —Ethan Bernstein, Jesse Shore, and David Lazer, “How Intermittent Breaks in Interaction Improve Collective Intelligence”
Intermittent collaboration gives the best results. Researchers recently devised an ingenious experiment to assess the effectiveness of team-based solutions to complex problems. Bernstein and colleagues found that “groups whose members interacted only intermittently . . . had an average quality of solution that was nearly identical to those groups that interacted constantly, yet they preserved enough variation to find some of the best solutions too.”1 Intermittent collaboration found better solutions than constant interaction.
“The roots of Toyota’s success lie not in its organizational structures but in developing capability and habits in its people.”
Without joint responsibility, there is a danger of loss of trust if something goes wrong.
With X-as-a-Service, there is great clarity about who owns what: one team consumes something that the other team provides.
Promise theory as a way to design systems for team interaction. Promise theory—devised by technologist and researcher Mark Burgess—explains how and why it is preferable to construct inter-team relationships in terms of promises rather than in terms of commands and enforceable contracts. For example, by adhering to the meaning of the major/minor/patch/build numbering indicated by semantic versioning (SemVer), the team promises not to break software that depends on their code.
Allan Kelly—longtime advocate of using the reverse Conway manuever to shape teams, says: “someone who claims to be an Architect needs both technical and social skills. . . . They also need a remit that is broader than pure technology—they need to have a say in business strategies, organizational structures, and personnel issues, i.e., they need to be a manager too.”
Collaborate on potentially ambiguous interfaces until the interfaces are proven stable and functional.
Dynamic Reteaming by Heidi Helfand provides many useful recommendations for making team changes as smooth as possible.
Techniques from domain-driven design (DDD) such as event storming and context mapping can help accelerate awareness of appropriate boundaries. See Chapter 6 for more details on DDD.
three core team interaction modes provide the clarity needed for all team interactions within the organization: Collaboration: two teams work closely together for a defined period to discover new patterns, approaches, and limitations. Responsibility is shared and boundaries blurred, but problems are solved rapidly and the organization learns quickly. X-as-a-Service: one team consumes something (such as a service or an API) provided “as a service” from another team. Responsibilities are clearly delineated and—if the boundary is effective—the consuming team can deliver rapidly. The team
...more
The design . . . is almost never the best possible, [so] the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.
Restrict any ongoing collaboration between teams to explicit valuable activity. Collaboration is expensive. Unnecessary collaboration is particularly expensive, especially as it can mask or hide deficiencies in underlying platforms or capabilities. Any ongoing collaboration activity must, therefore, be justified as valuable discovery, valuable capability building, or valuable deficiency-filling activity.
Evolve different team topologies for different parts of the organization at different times to match the team purpose and context.
This level of specialization introduces bottlenecks in delivery (as storied in The Phoenix Project and explained in The DevOps Handbook). The routine aspect can also negatively affect individual motivation.
Jeff Sussna, author of Designing Delivery,
organizations that build and run software systems need to ensure that their team interactions optimize for flow, Conway’s law, and a team-first approach (including team cognitive load).
By deploying the four fundamental team topologies with the three core team interaction modes, organizations gain crucial clarity of purpose for their teams on an ongoing basis. Teams understand how, when, and why they need to collaborate with other teams; how, when, and why they should be consuming or providing something “as a service”; and how, when, and why they should provide or seek facilitation with another team.
The combination of well-defined teams and well-defined interaction modes provides a powerful and flexible organizational capability for structural adaptation to changing external and internal conditions, enabling the organization to “sense” its environment, modify its activities, and focus to fit.
A second effect on performance of creating small, empowered units is to increase the likely speed of adaptation to new information. —John Roberts, The Modern Firm
We have deliberately omitted details of how to undertake large-scale transformations in an organization. For excellent patterns of organizational change, see the work of Mary Lynn Manns and Linda Rising.
Above all, share how the Team Topologies approach makes for better outcomes for humans, software systems, and the organization itself.
