Inter-team Dependencies - Chapter 2: Ontogenesis

Chapter 1, Genesis,? of this series covers why inter-team dependencies increase when you move from project to product and why that should not deter you. Now let’s explore three ways to deal better with the increase in dependencies. The first is a socio-technical solution, the second is in the realm of team design, and the third and most potent is a systems intervention.

1. Try Internal Open Source

Digital product teams usually own their code - for good reason. This is in contrast to project teams, where teams write to whatever codebases they need to. But unregulated and shared ownership of code often leads to the tragedy of the commons. I have noted before that unmaintainable code results - at least partly - from unmaintained (i.e. temporary) teams.

On the other hand, exclusive ownership of code reinforces inter-team dependencies among digital product teams. To alleviate this, you might try an internal open source model of development. It allows dependent teams to self-service their dependencies while at the same time, allowing the owning team to maintain control. So for example, instead of waiting on Team B to provide a modified version of an API, Team A could, under this model, agree on the change with Team B and make the change and submit it to Team B as a pull/merge request.?

A number of conditions must be met for this to work.

But You Must Be This Tall

Clear ownership requires clear boundaries. If you have monolithic and non-modular codebases, you’ll struggle to enforce an owner-contributor model. Note that this condition has nothing to do with the presence or absence of a monorepo.

In addition to modular codebases, you’d need the following:

• Team A must have the knowledge and skill to contribute to Team B’s codebase.
• Team B must make it easy to contribute by maintaining its codebase at the standard of a good open-source project.
• Team B must be available for contribution discussions and must review contributions promptly and constructively.
• The product development funding model must allow for the teams’ hours to be used in this manner.

This is not a simple ask for most large organizations. Most struggle to make it work. Even when it works, there is the risk that an option to self-service turns into an expectation to do so. Team B, in this negative scenario, just focuses on its own roadmap and fends off all requests from dependent teams asking them to self-service or wait indefinitely.?

2. Practice Secondment

If sharing access to the code is problematic, why not share access to the people that are familiar with the code? Developers from one team may be seconded to dependent teams for a short while. Not all of them, say up to 50%, on a rotating basis. By doing so, dependencies are insourced, in a way. Besides, seconded developers get to appreciate the concerns on both sides of a dependency. However, secondment only works well with developers that understand their home codebase well. Managers must resist the temptation to offer inexperienced developers for secondment while keeping the experienced ones to themselves. Secondment must be planned in advance - it doesn’t work for dependencies discovered on the fly.

3. Normalize Priorities

There is a way to reduce the coordination overhead of inter-team dependencies without resorting to the measures described above. We begin by recognizing the reason for some of the overhead. Consider a common scenario.?

Team Blue plans to work on a priority-one feature next quarter. They have a dependency on Team Black. But the product owner of Team Black says that they already have two priority-one items of their own in their plan for the next quarter. They decline to commit to servicing Team Blue’s dependency. Team Blue is stuck. But are Team Black’s priority-one items as important and urgent to the organization as Team Blue’s?

We won’t know unless priority scales are normalized across the organization. They are not usually normalized because product development teams have to deal with multiple stakeholders, each of whom have their own worldview of priorities. In theory, techniques based on "cost of delay" should help normalize priorities by serving as a common denominator. In practice, these techniques help only so much. How do you validate and normalize costs assigned by different stakeholders? The whole process is vulnerable to false rigor and gaming.

In my experience, this problem cannot be solved by attempting normalization at the level of work items. You must go a level higher. What outcomes are these work items in service of? Do that mapping. Develop a tree of outcomes and sub-outcomes if it helps the mapping process. Usually the number of? significant outcomes you are pursuing will be one to two orders of magnitude smaller than the number of work items to be taken up during the year.?

Prioritize Outcomes, Not Work

Next, persuade exec leadership to stack rank outcomes (or objectives, if you use OKRs). It can be a difficult exercise but it must be done at the level of executive leadership. If they are unable to get together and stack rank an organization’s priorities in terms of outcomes, their lack of consensus will show up as overhead at the time of negotiating dependencies.?

I am not always successful in getting executive leadership to do this but when I am, the next step is easy. Work items inherit the priorities of the outcomes they serve. I employ more rules when I do this. For example, dependencies inherit the priority of their parent work items (dependents). If a dependency has multiple dependents (e.g. two features both require the same new API), it takes on the highest of its dependents’ priorities. In terms of the previous example, you now have a shared and unambiguous way of answering if Team Black should commit to servicing Team Blue’s dependency.?

There’s a bit more detail in the video on this page.

Stronger Measures

The measures above will help you deal better with increased dependencies. But are there things you can do to limit the increase in dependencies in the first place, as you transition from project to product? The next chapter gets into this.

Until next time, take care and prosper.

Sriram

agileorgdesign.com