“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.
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.
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:
Understanding your scenario and striving to reduce dependencies to a bare minimum is essential. Doing that quickly pays off because dependencies slow progress down.
No matter the scenario, don’t let your team fall victim to the circumstances. You can always act and reduce dependencies. Here’s how:
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.
My approach is the following:
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:
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:
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 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, Product, UX, 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.
Kevin Morris talks about the importance of not overly focusing on the inward-facing components of product management.
While running a sprint planning ceremony is pretty straightforward, a lot of work goes into the planning both before and during the ceremony.
Sam Schulte, Vice President, Product Engineering at Inspirato, talks about the delicate balance between innovation and scale.