“We cannot reach our sprint goal because Team Blue didn’t solve the dependency. We’re blocked.”
When I heard that from our most experienced software engineer, I got annoyed because it put me in a powerless situation. It’s like we accept the case but decide not to act. That’s not me, so I decided to talk to Team Blue.
The product manager from Team Blue explained that they couldn’t deal with the dependency because Team Yellow had another dependency that blocked them. And there I was again, in the same situation with a different team.
Guess what happened when I talked to Team Yellow? They also had a blocking dependency, but at this time, with Team Green, and I was the product manager at this time. Curiously, I was unaware of such dependency.
How did we end up in such a nonsense situation?
I will walk you through it during this post, hoping you’ll understand and learn how to deal with dependencies effectively.
Skip ahead:
What’s a dependency?
Maybe you clearly understand dependencies, but I know that I stumbled upon some misunderstandings. That’s why I will briefly describe my understanding and ensure we’re talking about the same thing.
Suppose you work for a marketplace and are responsible for the search experience. You realized that you could optimize the search results by taking related product information. Yet, such information isn’t available. Another team takes care of product information management. That means to get your idea done, you’re dependent on the other team.
The above example is a product dependency, which happens when one team cannot finish something because of another team. You can face other types of dependencies, such as business and external.
Dependencies can be treated as blockers, but not all are the same. Sometimes you can identify alternatives and escape from the dependency.
Learn more →How to manage dependencies
If you fail to deal with dependencies effectively, you end up in horrible situations.
Coming back to my initial example about teams Blue, Yellow, and Green. What happened?
We worked with Jira, and whenever we had a dependency, we’d create a product backlog item on the response team’s product backlog. Then, we’d put our item as “blocked” due to the dependency. Of course, someone would drop a comment hoping it was enough.
In summary, we managed dependencies electronically and barely had conversations to solve them as a team.
Learning: Talk to teams instead of just creating tickets and expecting them to tackle them promptly.
The team’s setup plays a critical role in product dependencies. Let me clarify that:
- Component teams: when the responsibilities lie on the component level, teams will inevitably have to deal with several dependencies. This is a suboptimal way of working
- Cross-functional: teams with all the required skills to get the job done reduce dependencies. For example, some teams don’t have a dedicated designer because a separate team takes care of that. This approach forces dependencies and will create hassles. The more independent teams are, the more functional they become
Understanding your scenario and striving to reduce dependencies to a bare minimum is essential. Doing that quickly pays off because dependencies slow progress down.
Use technology in your favor
No matter the scenario, don’t let your team fall victim to the circumstances. You can always act and reduce dependencies. Here’s how:
- Events: benefit from an event-driven architecture. Ensure that events are published so interested teams can consume information whenever needed
- Mocked APIs: in some situations, you’ll need to interact with others’ domains, and you won’t have an API for that. Instead of creating a ticket and blocking progress, sit down with the team, agree on the API format, mock it, and conclude the application. It will still not be production ready, but you don’t get blocked
- Data exposure: it’s fundamental to have a strategy for how teams make their data available to others. Each team has a domain responsibility and eventually interacts with each other. Searching for a solution when you have a dependency is counter-productive. Having a strategy and knowing how to exchange data between teams is best. For example, the domain team that is responsible for offering APIs could be a strategy
Map dependencies early
Whether you like it or not, dependencies will exist, and you cannot ignore them. You can say you’re a product manager, not a project manager. I’d say you’re right, but choosing to ignore dependencies is the same as choosing to fail.
You don’t need to create a gigantic flow with all dependencies, timelines, etc. This will be a waste. We know we suck at estimates.
You can map dependencies, define the responsibility for solving them, — name the person, not the team — and define the type. Not all dependencies are the same. Some will block you, and for some, you have alternatives. Deal first with blockers and then with the others.
I could recommend you use Jira Project Plan or other tools to map dependencies. They would visually show a gigantic map full of connections, but I won’t. The reason is simple — a massive flow of dependencies will frighten people. My recommendation is to keep it simple and focus on collaboration.
Subscribe to our product management newsletter
Get articles like this to your inbox
My approach is the following:
- Name dependencies
- Define business criticality and how it blocks progress
- Use a 2×2 matrix to visualize your dependencies
- Prioritize the ones that block progress and are business-critical for now
- Drop the ones that are business irrelevant, and you’d have an alternative
- Define responsible and actions
- Rinse and repeat
Dependency map
You can ignore my tip and use a dependency map if that suits you best. Jira offers dependency maps out of the box. I don’t like them because people prioritize processes and tools over collaboration when they see a map like the following:
Key takeaways for dealing with dependencies
Dependencies are part of any product. You must understand them and define actions. Ignoring them is a wrong choice for everyone.
The key takeaways of dealing with dependencies are:
- Define a strategy to deal with technical dependencies — ensure your team knows how to reduce the impacts of dependency and continuously improve this strategy
- Never fall victim — instead of saying we cannot progress because of a dependency, ask what we can do now. Search for alternatives
- Not all dependencies are the same — some dependencies have alternatives, and you could benefit from them. Others, you must deal with. Don’t panic about dependencies. Mindfully deal with them
- Collaboration beats tools — overcoming dependencies is a teamwork exercise. Tools can help you visualize them and understand your current status but remember that the goal is to solve dependencies. Collaboration is your best tool for that
- Design to reduce dependencies — set teams as independent as possible. Also, strive to have a set of strategies in place that enable teams to know how to act when facing dependencies quickly
Additional point. Eventually, you will stumble upon a business-critical external dependency that will block progress if not solved. This is a dangerous type of dependency because it doesn’t depend on you. Ensure such dependencies are solved before investing significant time in a product or project. Otherwise, you’re betting on luck.
“It’s okay to admit what you don’t know. It’s okay to ask for help. And it’s more than okay to listen to the people you lead — in fact, it’s essential.” — Mary Barra, CEO of General Motors
Featured image source: IconScout
LogRocket generates product insights that lead to meaningful action
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
