See and Resolve Team Dependencies, Part 3: Some Component Teams, Some Feature Team

Johanna RothmanMarch 14th, 2022Last Updated: March 14th, 2022

0 67 3 minutes read

Continuing the series on dependencies…

Maybe you don’t have the problem where the team creates internal dependencies with their process. And you don’t have to wait for someone outside the team to approve your work—an organizational process. But you do have a combination of platform/component teams and feature teams.

I see this most often in products similar to the Integrated System Program kind of product. The platform (the bottom layer) offers some common services, possibly even an operating system type of services. While cross-functional teams develop and test those services, the Products (in the middle) use those services as if they are components.

All the teams are cross-functional teams—that’s not the problem. The problem is how the teams create features that the users can see. That’s what looks and feels like component teams.

The Products in the middle use components from the platform. That creates dependencies. And, as the product grows, sometimes the dependencies get worse.

Visualize the Components

You have a product that looks something like this: a common platform on the bottom, products or layers in the middle, and a common GUI on the top. Features make a “round trip” from the GUI to the platform and back again. (I realize I’m simplifying.)

As the product grew, the red and teal features get wider. However, they’re both relatively self-contained.

Features get wider for several reasons:

The company supports many previous releases.
You need backward compatibility for some reason.
Teams don’t refactor as they proceed and they get bloated code.

The wider the red and teal features are, the more of a challenge for anyone to change them quickly and easily. Those features need more tests and more review. And note that since the feature teams in the Product layer request the component teams in the Platform layer to change, we have dependencies between teams.

The dependencies between teams don’t stay static. The longer the time for the Platform teams to change, the more the Product teams tend to create “helper” features.

In this image, the purple and yellow features are separate, but overlap the original red and teal features. The teams no longer release them independently.

Here are the problems I see:

Teams can no longer release each of the features independently. They can only release red and purple together and yellow and teal together. That means it takes longer for us to release anything.
We suspect we should refactor. But how safe is that, given how big everything is now?
Our cross-functional teams might have to get larger to support all this extra work.

What can you do? Start small to reduce complexity.

Reduce Complexity

You might be tempted to say, “We need to rearchitect the entire product!” Say that all you want. Please don’t do it. My experience is you don’t yet know what you need. Instead, start small to reduce complexity, one small piece at a time. (Besides, your customers and management still want lots of features.)

If you have dependencies between Platform/Services teams and Product/Feature teams, consider these options:

How small can you make the next batch of features? What can you choose for a minimum for your next feature or feature set? (See Consider Product Options with Minimum Outcomes.) Avoid the trap of implementing everything instead of a minimum.
Everyone uses continual integration to see the new changes every day, at minimum.
If you do think it’s time for a re-architecture, what’s the smallest experiment you can do to see your options?
How many teams might collaborate on separating the various features into small, thin slices that do not require helper features? How can those teams work together for a few weeks to a few months? (I normally prefer smaller teams, but sometimes, multiple teams can collaborate on separating intermingled features.)

If you’re wondering how things got this way, I see two common causes:

The teams chose their previous actions as shortcuts. Now, their technical debt has come due.
The teams did not choose shortcuts. They got tired of waiting (or had pressure) and did not wait for the architect. And because they did not have architecture expertise, they made mistakes. Yes, the dependencies from See and Resolve Team Dependencies, Part 2: One Person Outside the Team became visible in the product.

Don’t blame the team. They reacted to the (management) pressure of “more features faster.”