How To Do Dependencies Management as an Agile Product Team

As you may know, I invented the Now-Next-Later roadmap because I believe that roadmaps should be about discovery, not deadlines. But how do you create and manage an agile roadmap while also juggling dependencies management?

This is a question I get asked a lot. Of course, there will be times when dates and dependencies are important and you may want to – or be under pressure to – include them on your roadmap. But you should always think about why the dependency exists – whether it’s necessary for your product strategy or if it’s a dependency just for the sake of it. 

It might seem daunting, but once you’ve read this article you’ll be the dependencies management ninja you want to be – and you can always bookmark this for reference in the future too.

In this post we’ll run through:

• What are dependencies?
• What is dependencies management?
• Types of dependencies
• How to do dependencies management on your roadmap
• How to do dependencies management on your product portfolio

What are dependencies?

Let’s start by looking at exactly what we mean by dependencies. They are the relationships between pieces of work that determine the order in which a piece of work must be completed by Agile teams. 

Looking for an example to show you what this means? Well, we’ve got a dependency right here. This article you’re now reading first had to be written, then it had to be reviewed and edited before it could be published. The relationship between these two pieces of work – the writing and then the subsequent reviewing – is a dependency. It reduces the risk of errors, but it increases the complexity of the process and the time taken to get the article published. 

On-balance dependencies are a good thing. It doesn’t have to cause a problem, but any dependency does have to be thought about and planned for to minimize the disruption it might cause.

You often come across dependencies in cross-functional product teams. They can play a major part in both enabling and disrupting your product development and delivery plans. Dependencies management is important.

What is dependencies management?

Dependencies management is the work of measuring, analyzing, and minimizing the disruption caused by dependencies. Effective dependency management will increase the predictability that your product will be released in line with your plans, so what does it entail?

You’ll need to identify the relationships between pieces of work, recognize dependent activities, visualize them and map them on your roadmap. It’s almost certain that you’ll have to rely on another team when you’re developing a product, so to effectively manage roadmap dependencies, you’ll also need to track them with the right groups or teams throughout your roadmapping workflow. 

You might conjure up images of project plans and Gantt charts when you hear the term dependency, but product managers need to concentrate on dependencies that are strategic. A dependency is only strategic if poor planning affects the ability to solve the customer problem. Let’s run through the different types of dependencies and look at how you might deal with them.

Types of dependencies agile product managers will face

There are several ways to categorize dependencies and your dependency management will be improved if you can distinguish between them. Ask if your dependencies are logical, internal or external, mandatory or discretionary, and what their nature is – do they run from finish to start, start to finish, and so on? We’ll go through these below.

1. Internal or external dependencies

An internal dependency is within the team’s control. An external dependency is outside the team’s control and relies on a relationship with other teams, functions, or organizations. Investor funding, an operating license, and goods or services from a third-party supplier would all be external dependencies, for example.

2. Mandatory or discretionary dependencies

A mandatory dependency means one step must be completed before another step. In project management, a mandatory dependency is sometimes referred to as hard logic. For example, the signing of a contract before work can start, putting a privacy policy in place before gathering personal data, and a company procedure like signing off on research expenditure are all mandatory dependencies.

A discretionary dependency is more of a ‘we should’ than a ‘we have to’, the type of thing that would be seen as best practice by an Agile team. Do you integrate a payment gateway into an app before an email system? It’s largely a matter of experience and personal preference as to which one is done first.

3. Time-sensitive dependencies

These dependencies are usually split into four types: start-to-finish, finish-to-start, start-to-start, and finish-to-finish.

1. A start-to-finish dependency means task 1 can’t finish until task 2 is started – they’re not very common. The switchover from a legacy system to a new IT system would be one example, you can’t shut down the old system until the new one is up and running successfully.
2. A finish-to-start dependency means task 2 can’t start till task 1 has finished. This article can’t be reviewed and edited until it has been written for example, and you have to have developed an app before you can list it in an app store. It’s the most common type of dependency.
3. A start-to-start dependency means task 2 can’t begin till task 1 is started, but task 1 does not have to be finished before task 2 can start. You might start to put together questions for focus groups based on some initial findings from customer feedback questionnaires, for example.
4. A finish-to-finish dependency means that task 2 can’t be completed till task 1 is completed. For example, you might start putting together focus-group questions from initial responses to customer feedback questionnaires, but you won’t finish until all your questionnaires have been returned.

4. Logical dependencies

Also called causal dependencies, these are those pieces of work that are necessary for a project to be completed. For example, if there just aren’t enough people on a team to get the work completed then recruiting an additional team member or getting someone in on secondment to get the work finished would be a logical dependency. You have to do product research before you can analyze it and act on your findings in order to improve your product – these are more logical dependencies.

How to do dependencies management on your roadmap

Let’s now take a look into the practicalities of dependencies management for your roadmap. While we’ve written persuasively and at length about how product managers should avoid having timelines on their roadmaps, I mentioned earlier that there are times with dependencies management when a date on your roadmap will add value. As you can see it’s all about understanding whether dependencies are strategic or not.

Such a situation occurs when the date is strategic when you’re solving a problem arising from regulatory or legal compliance for example. The enforcement of GDPR regulations in 2018, which led to a deadline that most companies had to work to, is a great example of an external, mandatory, and time-sensitive dependency!

If the value of the work is dependent upon the time then it’s important to know that when you’re planning. Do you need to deliver something in time for an industry conference? Late delivery would result in reduced value – so the dependency is strategic.

You can be lean, reactive to your market, and able to pivot with a product roadmap. You have the flexibility to change your plans and solve problems instead of being a feature factory. Below, the roadmap card is communicating a strategic dependency, the externally driven date is what makes it strategic.

Remember, not all roadmap initiatives need dates

When using dates is not okay

Dates added to the roadmap because of sales, or demands from the CEO are not strategic, nor are they dependencies. In such cases as these, my advice would be to follow that time-tested approach of asking why they’re there. If the date serves the purpose of delivering short-term gain from additional sales opportunities, then product managers should highlight the long-term pain that inevitably comes from producing a Frankenstein product. 

Perhaps the request for a date on the roadmap comes from senior leadership or investors who need to feel in control. In such a situation a product manager should highlight how a robust discovery process involving lean, iterative development reduces risk. If there is a genuine need to plan ongoing activities for marketing or sales or to inform resource planning, then product managers should work with the delivery team to create a release plan rather than accept a date on the roadmap.

By treating internal requests for dates seriously and offering a better proposal for solving the underlying problem, you’re exercising your product management muscles for more than just the development of customer solutions. Through effective dependencies management, you’re helping your stakeholders understand the value of good product culture. 

How to do strategic dependencies management on your portfolio roadmap

A solid approach to handling strategic dependencies on a portfolio roadmap is to separate the strategy from execution. You should always build a strategic roadmap that is based on end-user value. Are you building something new that involves work from multiple teams? No problem! Define your initiative, including ideas that relate to all the separate moving parts. Stop trying to juggle different roadmaps for different delivery teams. Focus on a single initiative and determine what’s needed to deliver it.

If you define your changes in this way it becomes much easier to understand what’s needed to deliver end-user value. The method of execution is irrelevant. It’s easier to reprioritize, too. If you move an initiative forward or backward in your priorities, all the associated component changes go with it. Separating teams (with team-specific releases) can manage the execution and resource planning. If your organization goes through a detailed budget approval process, it’s much easier to see what’s required and what funding is needed.

Strategy first is the way to go

Dependencies aren’t going anywhere so it’s important for product managers to recognize them and work out ways to deal with them. We all know how easily digital products can turn into complex and unwieldy beasts. 

Effective dependency management is one of the key ways you can keep a check on this tendency. It should help you work out the proper flow of tasks, and increase predictability and efficiency, reducing both the risk and the time it takes to develop and deliver a product. 

When working with dependencies, it’s important always to put strategy first. And we know that working with a lean roadmap is a great way to inspire strategic conversations. By providing guidance on problems to be solved rather than showing what will be delivered, a lean roadmap helps your stakeholders to focus on the problems rather than on how they will execute a strategy. Using this approach makes it easier for you to plan, prioritize, and adapt, especially when the moving parts are complex. 

Be sure, then, to simplify the way you structure your product portfolio. And, as I mentioned above, you should be sure to base it around value rather than the codebase – so that you group your work across platforms and can focus on what’s needed to deliver each initiative rather than juggling different roadmaps. For example, a multi-platform business such as Netflix might group its work around customer experience rather than around its various web platforms and its apps, so that the customer experience is consistent whatever platform the customer chooses to use.

I’ve no doubt that you will then find that:

• Your product portfolio will be more straightforward
• You’ll have a more streamlined approach to planning
• The risk when planning will reduce

It seems like a no-brainer, so why not book a demo with one of our product experts for more information? They’ll show you how ProdPad can support you when aligning teams and stakeholders with your product strategy.