What to do. First, you want the dependent team to own their piece of work as much as possible. Give them all necessary permissions and access to the shared codebase. Delegate responsibilities and decision-making. For example,
let them deploy the subsystem they manage on their own instead of reserving this right to a dedicated infrastructure team. Train them to develop in the shared code base and perform delegated activities. Set up the process of code review to avoid drops in code quality. A developer from an expert team may join a dependent team to quickly boost its expertise and make cross-team code reviews less necessary. Second, look for technological ways to cut the dependency between the two teams. Without it many of the steps mentioned above won't be possible. Although, even decoupling subsystems in itself may help the teams become more independent. For instance, in Example 7.2 the dependent team may move some of the built-time settings to run-time. As a result, they will be able to fine-tune the application settings themselves, without the involvement of an infrastructure team.
When to apply. As the name suggests, this strategy is a good fit when unplanned work comes in a form of requests from a downstream team. Typically, these requests are blockers for the team that creates them.
Scope of application. Product life cycle.
Type of action. Fixing the root cause.
Costs and risks. Both teams will need to spend an effort to remove the dependency. This includes knowledge transfer sessions and trainings, studying the new code base, and implementation of technological improvements. Moving a team member from one team to another also takes time for both teams to get used to the new setup. This may influence the velocity of both teams. In addition, since any changes in the team's structure
may trigger the reforming process, there is always the risk to spark a conflict that will require specific attention.