Team Topology

Team topologies by Matthew Skelton and Manuel Pais

Goal: Achieve flow.

Common Software/Product development issues

1. Teams struggle with the cost of switching contexts.
2. Teams lack the bandwidth to pursue mastery of their trades.
3. Reverse Conway maneuver: The goal is for your architecture to support the ability of teams to get their work done — from design through to deployment — without requiring high-bandwidth communication between teams.

Team structure and composition

1. Teams achieve remarkable feats not simply because of the individual qualifications of their members but because those members coalesce into a single organism.
2. A single team should have between 5 to 8 people.
3. If it takes three months for a team to become highly effective, we need to provide stability around and within the team to allow them to reach that level.
4. There is a ramp-up period necessary to bring people up to speed, but the communication lines inside the team also increase significantly with every new member. Also, there is an emotional adaptation required both from new and old team members in order to understand and accommodate each other’s points of view and work habits. (Reference: Mythical man month, Tuckman’s team developmental model.)
5. Tuckman’s Team performance model

• Forming: assembling for the first time
• Storming: working through initial differences in personality and ways of working
• Norming: evolving standard ways of working together
• Performing: reaching a state of high effectiveness
• However, in recent years it has been observed that the storming actually takes place continually throughout the life of the team.

Team composition

1. Every part of the software system needs to be owned by exactly one team.
2. The danger of allowing multiple teams to change the same system or subsytem is that no one owns the changes made or the resulting mess. However when a single team owns the system or subsystem and then the team has the autonomy to plan their own work, then that team can make sensible decisions about short-term fixes with the knowledge that they will be removing any dirty fixes in the next few weeks. Awareness of and ownership over these different time horizons helps a team care for the code more effectively.
3. Note that team ownership of the code should not be a territorial thing. Teams should view themselves as stewards or caretakers as opposed to private owners of the code. Think of code as gardening not policing.
4. Promote a team-first approach. Provide team first working environment. Minimize team distractions.
5. Restrict team responsibilities to match team cognitive load. (Intrinsic, Extraneous, Germane, Relative domain complexity)
6. Limit the number and type of domains per team

• Assign each domain to a single team.
• A single team should be able to accommodate two to three simple domains.
• A team responsible for a complex domain should not have any more domains assigned to them, not even a simple one.
• Avoid a single team responsible for two complicated domains.

1. Eyes on hands of approach: Communicate goals and outcomes rather than obsessing over how. (McChrystal)
2. Minimize cognitive load on others.
3. We need to consciously design our teams rather than merely allow them to form accidentally or haphazardly. Avoid anti-patterns to shuffle team members. The superior “Sensing” ability comes from treating frontline staff and teams as highly valuable sources of signals about the market and environment in which the organization is operating. (Accelerate: Nicole Forsgren, Jez Humble, Gene Kim)
4. Product teams need a support system: Product teams depend on infrastructure, platforms, test environments, build systems, and delivery pipelines for their work to become available to end users. They might have full control over some of these dependencies but they will likely need help with others due to the natural cognitive and expertise limits of a team.
5. The key for the team to remain autonomous is for external dependencies to be non-blocking, meaning that new features don’t sit idle, waiting for something to happen beyond the control of the team.

Product teams need a support system

1. Product teams need a support system: Product teams depend on infrastructure, platforms, test environments, build systems, and delivery pipelines for their work to become available to end users. They might have full control over some of these dependencies but they will likely need help with others due to the natural cognitive and expertise limits of a team.
2. The key for the team to remain autonomous is for external dependencies to be non-blocking, meaning that new features don’t sit idle, waiting for something to happen beyond the control of the team.
3. Creating product teams without a compatible support system, consisting of easy-to-consume services and readily available expertise for tasks that the team is unfamiliar with creates more bottlenecks. Product teams end up frequently waiting on “hard dependencies” to functional teams (products, infrastructure, architects, networking, QA)
4. There is increased friction as product teams are pressured to deliver faster, but they are part of the system that does not support the necessary levels of autonomy.

Stream-Aligned teams

1. A stream is the continuous flow of work aligned to a business domain or organizational capability. Continuous flow requires clarity of purpose and responsibility so that multiple teams can coexist, each with their own flow of work.
2. A stream-aligned team is a team aligned to a single, valuable stream of work; this might be a single product or service, a single set of features, a single user journey or a single user persona.
3. The team is empowered to build and deliver customer or user value as quickly, safely and independently as possible, without requiring hands-off to other teams to perform parts of the work.
4. A stream-aligned team works on the full spectrum of delivery, they are, by necessity, closer to the customers and able to quickly incorporate feedback from customers while monitoring their software in production. Such a team can react to system problems in near real-time, steering the work as needed. (Don Reinertsen)
5. Capabilities within Stream Aligned Teams

• Application security
• Commercial and operational viability analysis
• Design and architecture
• Development and coding
• Infrastructure and operability
• Metrics and monitoring
• Product management and ownership
• Testing and quality assurance
• User experience (UX)

6. Why Stream Aligned team, not Product or Feature team?

• Customers interact with a discrete piece of software but with a range of products and devices that all run different kinds of software. Customers also interact with brands via multiple channels expecting consistent responses and interfaces.
• Continuous design capabilities: We treat ideas such as service, feedback, failure, and learning as first-class concepts. The best way to enable this is with a stream-oriented view of change with an emphasis on flow. (Designing Delivery: Jeff Sussna)

Incident Squad

• When an incident occurs with the live production systems, the support teams initially attempt to resolve the problem within the stream areas alone. If the problem is entirely within the stream there is no need for any other team to get involved.
• If necessary other stream-aligned support teams are brought in to help diagnose the problem; and if the incident affects many teams a dynamic “swarm” or “incident squad” of support specialists if formed from various support teams to triage the problem and restore service as rapidly as possible.
• By keeping support teams aligned to streams, we help to keep the streams as independent as possible. Avoid monolithization in prod env. (Conway’s law)
• Rapidly share knowledge of newly discovered limitations and flaws in the software systems, enabling support teams in each stream to feedback learning quickly into teams building the systems.

Evolving team interactions for innovations and rapid delivery:

1. Collaboration: working closely together with another team.
2. X-as-a-Service: consuming or providing something with minimal collaboration.
3. Facilitating: helping (or being helped by) another team to clear impediments.
4. Divergent thinking approach: Collaboration leads to new insights into how technologies work, with learning brought back into other teams. (Dr. Kyung Hee Kim, Robert A. Pierce)
5. The first collaboration mode is to visualize two teams with distinct expertise and responsibilities working together on a small set of things.
6. The second visualization os collaboration mode identifies that the nature of working together between teams can be almost total: although there were two originally two teams with different skills and expertise, now there is effectively a single team pooling expertise and responsibilities. (should not exceed Dubar’s number of 15)
7. X-as-a-Service: Each team should have a great clarity about which team owns what. There is also less mental context needed for each team, so the cognitive load on each side of the relationship is lower. X-as-a-Service is best for situations where predictable delivery is more important than rapid discovery.

High performing organization

1. System thinking: optimize for fast flow across the whole organization, not just in small parts.
2. Feedback loops: Development informed and guided by Operations.
3. Culture of continual experimentation and learning: sensing and feedback for every team interaction.

How to get started

1. Start with the team: As an organization, ask yourself, what does team need in order to –

• Act and operate as an effective team?
• Own a part of the software effectively?
• Focus on meeting the needs of users?
• Reduce unnecessary cognitive load?
• Consume and provide software and information to other teams?

2. Identify suitable streams of change.

3. Identify a Thinnest Viable Platform (TVP)

4. Identify capability gaps in team coaching, mentoring, service management, process improvement and documentation.

5. Share and practice different interaction modes and explain the principles behind new ways of working.