Backlog Management - About Dependencies
Recently, LinkedIn asked me to share my insights to be eligible for the "Top Voice" badge. I realized that I have something to share with my followers in a more extended way than typical (ChatGPT-generated) answers to those top-voice questions.
Definition and classification of dependencies
As usual, let's start with the definition, which is rather made on my own. When you need someone to do something so you can do your work, that is a dependency. Postponing the dependency means a delay in delivering your work and the expected outcome, which causes financial losses.
Your team/service can have one or several dependencies and be a dependency for someone else. Sometimes it can be both. And dependencies might be temporary when you need something to be done once or permanent when you continuously need something to operate.
There can be external dependencies, meaning that you are waiting for something to be done outside your organization. Or that will be done inside your organization, which is an internal dependency.
We can distinguish cross-team, cross-stream, and cross-department dependencies, each with its own peculiarities.
In my world, dependency means an API or a software library. In your world, that may be anything else, like a vehicle part or a plumber to fix a pipeline leak.
Dependency is a risk
Obviously, it is the most common and unpredictably dangerous risk. Dependency also means you are limited in control and authority to influence all aspects.
You can't eliminate all the dependencies, as a system can't act in isolation. It uses different systems on its level and is also embedded into higher-level systems. There is an entire discipline about that, and I have an essay on a book about it.
But if you can proceed without a dependency, you should try. If having an external dependency is economically justified but related to a business-critical part of the system, then it is better to proceed on your own. That is the reason why enterprises do a lot of their stuff in-house, even though it would be reasonable to use open-source or paid vendors.
Inside an organization, we should avoid duplicating functionality even though it is inevitable on a big scale. With an internal dependency, you should ask yourself twice whether you need it to achieve your goals and whether you can rely on those who commit to delivering it for you.
External dependencies
There is a simple rule: if an external dependency has no contractual obligations, then it is a void promise. Don't believe a salesperson who promises you a feature to be delivered in Q4. However, having a contractual agreement does not guarantee that a dependency will be resolved in time. Legal obligations are additional motivation, and it is better to have them than nothing.
You don't have much authority and control over the outcome from your position as a dependent. You provide clear input and your expectations. Then, you have a right to accept or deny the outcome if that does not satisfy your needs. Losing time and money in case of negative scenarios cannot be fully compensated.
Internal dependencies
Let's clarify that a contractor's team is an external dependency as it is technically outside your organization. If there is a team that consists of contractors inside your organization, then it is an internal dependency.
Compared to external dependency, you have more control and the ability to drive things in your expected way. However, if communication between teams is broken, it will still be a challenge.
The main advantage is that you can use administrative leverage: basically, call big guys to press on other guys to make them do what you need in the desired terms. But it may backfire in different ways: put yourself in a vulnerable position for higher management or deteriorate your relationship with folks on "the other side."
Key thoughts on managing dependencies
Transparency
- Establish all dependencies in a work management tool you are using (e.g., Jira) with ETA (Expected Time of Arrival).
- If an external dependency owner has no access to your "Jira," then create a placeholder and keep it updated.
- Build a dashboard or an Excel spreadsheet to have a comprehensive view from top to bottom.
- Be able to respond at any time by explaining the current state of affairs for any stakeholders.
Communication
- Keep weekly catch-ups for internal dependencies and bi-weekly for external ones.
- Define clear acceptance criteria; don't rely on someone else to do it instead.
- Take time to communicate things that seem to be obvious to you.
- Take time defining the naming convention to be aligned with terms and their definition; making a glossary is a good option.
- Remember, you don't have the knowledge and resources your dependency owners do. Otherwise, you would do it by yourself.
Timeline and commitments
- Consider risks of delay due to dependencies as they are almost inevitable.
- Consider working in parallel in time-sensitive cases where possible.
- Define and strictly follow API contracts established between the parties.
- If you did some work ahead of delivering dependency, be ready to change.
- If you are a dependency and have a dependency for yourself, don't commit until you confirm the commitments of your dependencies
Escalation
- Know an escalation path both on your and dependency's side when things go wrong
- Be quick to escalate.
- Avoid taking responsibility for what is beyond your control.
Next post with a case study