Managing Dependencies Between Teams: From Big Room Planning to Interface Agreements

You manage dependencies between teams in four stages: first reduce them by cutting teams along the flow of work, then make them visible, then plan jointly and finally agree interfaces in binding form. Which stage matters depends on the number of teams involved and on how often work crosses a team boundary. Anyone who measures the waiting time at handovers sees where dependencies really cost delivery time.

Dependencies are the most common reason why initiatives take longer than planned, even when every single team works briskly. One team waits for a delivery, another for a decision, a third for access to a system. Each of these waits is small on its own, but together they determine the lead time. This article sorts the types of dependency, compares the common approaches and gives criteria for choosing the approach that suits the size of the organisation.

What types of dependencies exist between teams?

Four types of dependency exist between teams: sequence, knowledge, resources and interfaces. A sequence dependency exists when a team can start only after another has delivered a result. A knowledge dependency arises when only one person or team understands a system or a business rule and everyone else has to ask. Resource dependencies concern scarce specialists, test environments or approvals that several teams need at once. Interface dependencies, finally, exist where the output of one team must fit the input of another technically or in substance.

The distinction has practical value because each type calls for a different remedy. You resolve sequences through planning, knowledge through distribution and documentation, resources through allocation or capacity building, and interfaces through agreements. Anyone who tries to handle all dependencies with one planning round solves at most the first type.

The origin of many dependencies is the organisation structure itself. Melvin Conway described in 1968 that organisations design systems that mirror their own communication structure. If work is cut by function, for example analysis, development, testing and operations, every initiative has to pass through all functions, and a handover arises at each boundary. How teams can be cut differently is described in the article on Team Topologies.

How much do dependencies actually cost?

Dependencies cost delivery time, and a simple calculation can put a figure on it. For a typical initiative you count the handovers between teams, estimate the average wait per handover and compare the total with the pure working time. The following example is illustrative. An initiative needs ten working days of pure effort and passes through six handovers with four working days of waiting each. Lead time is then 34 working days, and the share of working time in lead time is about 29 per cent. For more than two thirds of the time the work lies idle.

This metric, called flow efficiency, shows where improvement pays off. If the organisation halves the number of handovers from six to three, lead time falls to 22 working days without anyone working faster. Which metrics suit the measurement is shown in the article on flow metrics.

Which approaches suit which size?

The suitable approach depends on the number of teams working together on an initiative and on how frequent the handovers are. With up to three teams, direct agreement is enough, supported by a shared board. With four to seven teams, a regular exchange between team representatives, known as a Scrum of Scrums, plus a shared overview of dependencies is advisable. From about eight teams delivering a shared outcome, a joint planning event for everyone involved, big room planning, pays off.

Big room planning is the common name for the planning of a program increment in the scaling framework SAFe, usually held over one to two days every eight to twelve weeks. All participating teams plan together in one room, show their dependencies on a board and resolve them in direct conversation. The strength of the approach lies in simultaneity: questions that would otherwise wander between teams for weeks are answered in one afternoon. The weakness is the effort. Tying up around a hundred people for two days costs capacity, and without preparation through clear priorities the event turns into a hunt for dates.

What does a good interface agreement look like?

A good interface agreement records in writing what a team delivers, in which format, by when and who decides on changes. It is short, readable on one page and describes both the delivery and the expectation placed on the recipient. For software, the agreement can be kept as a description of the technical interface, and for business handovers as a checklist with entry criteria. Where a team serves many others, such as a platform, a service description naming response times and contacts supplements the agreement.

Team Topologies distinguishes three forms of collaboration here: close joint work over a limited period, use of a team as a service with a clear interface, and facilitating support in which one team passes knowledge to another. The choice of form determines how much coordination is needed permanently. A service with a stable interface causes hardly any coordination effort after set-up, whereas close collaboration ties up both teams for as long as it lasts.

A frequent mistake is an agreement without a change process. Requirements change, and an interface that can be adapted only through escalation produces exactly the waits it was meant to avoid. Define who decides on a change, how early it is announced and how long the old version remains valid.

Reduce dependencies before managing them

The lasting solution is to reduce dependencies before managing them. Three levers serve this. The first is a team structure along value streams, so that one team can deliver an outcome from beginning to end. The second is building missing skills into the team, such as testing expertise, so that not every delivery waits for a central test team. The third is reducing shared resources through self-service, for example automatically provisioned test environments.

For initiatives that are meant to deliver in a bounded, fixed period, the working model can also limit dependencies. The article on Shape Up presents a model that assigns an initiative to a team as a whole, and the article on release planning explains how dates are kept when several teams contribute.

Managing dependencies with Niehues Consulting

Niehues Consulting is a consultancy for AI management and organisation design from a delivery perspective, based in Düsseldorf. Founder Marin Niehues builds organisations that deliver, on projects ranging from VC-funded scale-ups to DAX 40 groups and in more than 20 countries on six continents. In the service line delivery management and organisation design he works as delivery manager, project manager or product owner at exactly the places where work gets stuck between teams.

The approach follows the Niehues Delivery Model with three phases. Two test questions count for dependencies: who decides, who delivers, who uses? Which roles, decision paths and interfaces does operation need? Where these questions are open, the waits arise that the calculation above makes visible. The entry point is a free initial consultation of 30 minutes, which you can arrange via the contact form.