chapter 2

Team Dependencies

Dependencies between teams are a reality in any organization, even when we try to minimize them. If we don’t track team dependencies in the first place, we will run into scheduling and prioritization problems that slow down the flow of delivery. To understand inter-team dependencies, the work being done by each team needs to be visible. Once we are able to track these dependencies, we can then look into promoting healthy dependencies and removing (or minimizing the impact of) slowing or blocking dependencies. This chapter explores techniques to track and manage inter-team dependencies that work in a remote context.

Team API

The first step to start identifying team dependencies is for each team to clarify and provide visibility to the whole organization on the work they are currently doing and their priorities for the (near) future. Rather than starting with a top-down view of all the work in progress across the organization, we should promote that each team surfaces and exposes that information to others in all directions (upward, sideways, and downward) in an easy-to-consume way.

This decentralized approach also supports the fact that different teams might prefer to work with different timescales. For instance, some teams might only plan the current two-week sprint and prioritize high-level work items for the next couple of sprints, while other teams might do detailed monthly or quarterly plans. Teams also work with different artifacts—Scrum or Kanban boards or planning documents—depending on the team’s approach to work and, sometimes, the nature of the services they are delivering.

In Chapter 3 of Team Topologies we introduced the idea of a team API, a clear interface describing different aspects related to team ownership, communication preferences, practices, and principles. For example: Which artifacts does the team own? Which practices do they use to develop, test, version, and deliver those artifacts? Etc.

In the context of remote teams, it is even more important to include in the team API the road map for upcoming work as well as communication preferences, such as which channels (e.g., chat tools, video conferencing, email, or phone) they use, which days of the week and times are more suitable, and what the expected response time on asynchronous channels should be.

Making access to information and the team as clear as possible minimizes the cognitive load on others. It allows people to quickly find out who they need to talk to for a specific question, as well as when and how to talk to a specific team when it is needed. Even in situations where the team API does not provide all the necessary details, it should at least clarify when and how best to reach the team with further questions.

In addition to communicating preferences to other teams, the use of team APIs encourages a team to deliberately consider how they want to be viewed by and how they want to interact with people outside of the team. Teams can begin to define their own API independently from each other. This can lead to increased clarity and more purposeful communications and interactions between teams, provided they follow a consistent format that is easy to consume by people outside of the team.

Example

In the first half of 2020, Zoom and other video communication tools saw exponential growth due to worldwide lockdowns caused by the COVID-19 pandemic. This unexpected growth put a great strain on these companies’ infrastructure and security. It’s not hard to imagine an identity management team in this situation buried with change requests to natively support more runtime platforms as well as fix security issues getting media attention. Let’s look at a fictitious company, Mooz, and their fictitious identity management team.

The use of a team API for the Mooz identity management team is even more critical in this situation, as the team attempts to navigate the storm of work befallen upon them. When a team like this is under pressure to deliver on their goals, the use of a well-known, easy-to-access team API could help other teams and individuals in the organization communicate their needs or issues in a way that is efficient for this team, reducing interruptions and their need to context switch. This will allow the identity management team to focus on the work at hand. There may be a need for other teams to collaborate with them for a short period in order to configure their authentication workflow.

The team API can also be used to define how the team prefers to use chat communication tools, such as Slack. (In fact, at the company Slack, instructions for how to request help from a team are often pinned to the channel.)1 For more complicated situations, a workflow builder can be used to ensure all requests are asked in a consistent, pro-forma enforced structure. The team should also look to be more purposeful about how those Slack channels are organized where possible.

The following team API example is from the imaginary Mooz identity management team.

Now Your Turn

Think about a team within your current organization. What might their team API look like? Put together a team API that provides members of your organization who are outside of that team a clear description of the team’s purpose, their ways of working, and how they interact with other teams. Next, think about where you might want to store the team API to make it easily accessible to other members of your organization.

Team API Exercise

Use this template to help your team(s) think about their team API. Each team should answer the questions and fill in the details below. Remember that the answers and details will be a point-in-time snapshot of team relationships and team interactions.