Team topologies
New innovative ways of team collaboration
Team topologies is a new concept (teamtopologies.com) introduced by Matthew Skelton and Manuel Pais, authors of the book “Team Topologies” in 2019.
Why agile alone is not sufficient
agile development used to be the de-facto standard for product development in the new era to take care of business agility with shorter release cycles of features. essentially agile method takes care of:
- Budget
- Cost
- Scope
- Value
- Response to change
- collaboration
The speed of change is so drastic these days that even the traditional agile-based model alone would not suffice. The following graph shows predicted improvement rates (in percentage per year) for all 1,757 technology domains. Domains to the right of the red dashed line are improving faster than 36.5 percent per annum, the predicted rate for integrated chips according to Moore’s law (https://en.wikipedia.org/wiki/Moore%27s_law).
Team topologies augment the traditional agile model with the following to handle the changes effectively:
- temporal thinking
- team composition
- differentiated collaboration
- team responsibilities
- team productivity
To handle the next generation complexities, team topologies introduce concepts as the following:
- Cognitive load- Cognitive load is the total mental effort it takes to process information related to reasoning and decision-making; the same parts of the brain you use to browse a website or use an app. This information is stored in your working memory, which is part of your short-term memory.
- Team topologies are a collection of techniques for organizing teams, what functions these teams perform, and how the teams communicate with each other to develop the most significant possible value and good flow. It is a collection of teams and team structures with clear and limited areas of responsibility. The four basic topologies or team types: are value stream, platform, enabling, and complex subsystem teams.
- Team API — With stable, long-lived teams that own specific bits of the software systems, we can begin to build a stable team API: an API surrounds each team. An API (Application Programming Interface) is a description and a specification for how to interact programmatically with software, so we extend this idea to entire interactions with the team.
- Convoy’s law — is an adage that states organizations design systems that mirror their communication structure. It is named after the computer programmer Melvin Conway, who introduced the idea in 1967.[1] His original wording was:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.[2][3]
— Melvin E. Conway
Cognitive load
Definition
Cognitive load is the total mental effort it takes to process information related to reasoning and decision-making; the same parts of the brain you use to browse a website or use an app. This information is stored in your working memory, which is part of your short-term memory.
“You build it, you run it, — Current trend in SDLC
- Intrinsic cognitive load, which relates to aspects of the task fundamental to the problem space. Example: How is a class defined in Java?. you should attempt to minimize the intrinsic cognitive load (through training, good choice of technologies, hiring, pair programming, etc.)
- Extraneous cognitive load relates to the environment in which the task is being done. Example: How do I deploy this component, again?. Eliminate extraneous cognitive load (boring or superfluous tasks or commands that add little value to retain in working memory).
- Germane cognitive load, which relates to aspects of the task that need special attention for learning or high performance. Example: How should this service interact with the ABC service? — More space for “value-added” thinking
Key points
- Size of the software system Vs. the cognitive load of the team
- Team-shaped software architecture — support and operability
- minimize extraneous cognitive load also leads to the need to focus on developer experience and operator experience
- By using explicitly defined platforms and components, your teams will be able to reduce their extraneous cognitive load
- capacity for acquiring or improving business-oriented aspects
Anti-patterns
- Obscure commands or arcane configuration options increase the (extraneous) cognitive load on team members
- waiting for another team to provide infrastructure tickets or update configurations. This interrupts the flow of the dependent team, again resulting in a reduction in the effective use of cognitive capacity.
- Obscure commands or arcane configuration options
- waiting for another team to provision tickets for infrastructure or to update configurations
Solution
- Well-defined team interaction patterns:
- Collaboration: Working together with another team for a defined period to discover new ways of working, new tools, or new solutions.
- X-as-a-service: Consuming or providing something “as a service,” with a clear API and expectations around service levels.
- Facilitating: Helping (or being helped by) a team to gain new skills, domain awareness, or adopt new technology.
independent, stream-aligned teams:
- Stream-aligned teams are aligned to the stream of change required by a segment of the organization, whether a line of business, a market segment, specific geography, or government service.
- It is essential to ensure that stream-aligned teams can analyze, test, build, release, and monitor changes independently of other teams for most of their work.
- remove unhelpful extraneous cognitive load, allowing teams to focus on the intrinsic and germane (domain-relevant) aspects of the work
- self-service
Thin viable platform
- the smallest set of APIs, documentation, and tools needed to accelerate the team development of modern software services and systems. Such a TVP could be as small as a single wiki page that defines which public cloud provider services other teams should use and how
- thin the platform supports the force multiplier effect.
- Developer experience !!!
Team topologies
as explained earlier, team topologies are techniques for organizing, functioning, and effectively communicating among teams.
This model changes the authority model within the team however does not impact the team composition, as explained below:
Solution
Team topologies define four distinct teams:
- Stream aligned product team is perhaps a better name; it is the type of team you have the most of in a product development organization. They handle all or part of a product, service, user journey, or the like. They are interdisciplinary and can deliver increments of a product without being dependent on other teams. Other types of teams exist to support these teams.
- Enabling teams: Assist other teams for a short period as part of a transition or training period.
- complicated-subsystem teams: They take care of special subsystems and are only used when necessary
- Platform team: works with the underlying platform and supports value stream teams by simplifying complex technologies and reducing the cognitive load for the teams using the platform. Enabling teams assist other teams for a short period as part of a transition or training period. In addition, there are complicated-subsystem teams. They take care of special subsystems and are only used when necessary.
Team API
Definition
With stable, long-lived teams that own specific bits of the software systems, we can begin to build a stable team API: an API surrounding each team. An API (Application Programming Interface) is a description and a specification for how to interact programmatically with software, so we extend this idea to entire interactions with the team.
Key points
- Team API can consist of “just enough” documentation
- Information that is likely to be beneficial to the team itself (internally facing)
- Information that is likely to be helpful to other teams and stakeholders (externally facing)
- content structure) that we use to be reasonably consistent from one team to the next,
Anti-patterns
- Team A must ask Team B where to find information about their code artifacts.
Solution
Define API topics e.g.
- Code: Endpoints, libraries, clients, UI, data stores, etc. produced by the team
- Versioning: How the team communicates changes to its code and services
- Documentation: How-to guides, Team Calendar, Team Members, Team Mission, Business Objectives, Team Roadmap
- Dependencies: two ways
- Practices and principles
- Work information
