Dependency mapping is a complex thing. A bit like teen sex, everyone says they are doing it, most aren’t, & the ones who are, just aren’t doing it right. Unlike teen sex though there isn’t a project that doesn’t have at least one or two up/down stream dependencies. More often its many. Certainly, when you’re a delivery manager this is a typical scenario to try & resolve so that’s what I wanted to talk about today, how I do it. There is (as is often) no prescriptive right or wrong answer, & I’m hardly an academic but these are the ways which consistently work for me. I wanted to share them with you.

Agile team structure

Let’s firstly think about the team. Agile teams are meant to be cross-functional, somewhat atomic & capable of delivering something entirely independently. But that never happens. Well, mostly. Because the projects are often massively complex. So what does happen is friction. It’s that friction which delays projects. As I mention later, one of the things I like about Agile In particular (and there’s a lot to not like being honest) is the inspection & adaption – that can often unlock this friction & enable progress. So, in that spirit my approach to any complex project is often to surface risk as early as possible. Then formulating strategies to deal with them. Remember, Agile is meant to work where Scrum teams have everything they need to work independently. Most projects don’t work like that. So this is a common problem.

What are the dependencies exactly though?

In Scrum, the backlog is the main planning component & tool used to inform the direction of the Scrum team. The backlog consists of tasks, with acceptance criteria, & user stories hopefully following the INVEST principle. In an ideal world all tickets would be beautiful

& written perfectly but that’s for another post. Ultimately though everyone has to work through the backlog. A dependency is any link between any terminal element of a project. A simple example would be you want to make some toast, but you need the shop to be open to buy bread, you need a toaster, you need somewhere to plug the toaster in – these are examples of dependencies.

But don’t dependencies break Agile?

If you look at Scrum, it states that each team has sufficient & everything they need to deliver the thing as I mentioned earlier. Even one dependency ruins that notion. But dependencies are unavoidable. They are a reality of scaled Agile environments & it’s better to tackle them than not. As I study more & more from a observed level of why projects fail or not, this is one of the conflicts. Agile is implemented but can’t operate in the way they need to, i.e.. Independently because of these dependencies.

The Law of Constraints & Brooks law, written about on leadingagile.com (a website I love) an interesting read in managing constraints rather than dependencies. I’ve stolen this paragraph as its beautiful & explains the notion better than I could;

The solution lies in the application of Kanban to model the flow of value across teams, to make smaller investment decisions at the portfolio level, to limit the amount of work in process, and to redeploy people and teams in ways where everyone all the time, is focusing on the highest value initiatives within the organization. We use Agile at the team level to inspect and adapt and to make sure we are always focusing on delivering the most value possible in any given sprint. Using Lean and Kanban and TOC gives us that same ability when we are dealing with dependencies at any level of the organization.

leadingagile.com

Quality tickets in your backlog

As part of the ticket grooming & creation process a dependencies map should be considered. There are so many ways to do this, usually visually & of course, the more complex the thing, the more difficult the creation of the dependency map becomes.

It hopefully looks something like this as a baseline process;

The three amigos are your key here in my opinion. People who span all the different parts of the project. Doesn’t matter if the project is chunks of work, vision or specific products, you need a core & small amount of people to be aware of each bit & to then orchestrate information into the team. DO NOT have lots of people doing this, it’s called three Amigo’s for a reason & yes whilst you can scale it, it’s often better to not do.

So you’ve got yourself some dependencies, now how can you map them?

The Dependency Spider

The Dependency Spider diagram is described in the Agile Coach Jimmy Janken’s eBook Toolbox for the Agile Coach

I like this method. Its visual & it’s a complexity leveller. Everyone gets a picture & a physical line shows a dependency which means something. You can use diagramming software, Coggle.it is good, Monday.com is good, you can visualise using Miro or Microsoft Whiteboard or you can do a manual drawing. You could use Jira, but then who wants to use Jira? Joking aside, I find visual mapping really helpful in most projects. Simply just draw out the problem draw some lines, bring teams in & start talking about it & validating it.

Using Agile events

That leads me neatly onto Scrum of Scrums which as an Agile event, is a pretty good event if run properly. For me, the most important element of Agile is the inspect & adapt part, the self-reflection/retrospective & the ability to then act on that. Often in cases where you’ve got many people all working on the same or related things, this check in mechanism can really work – coupled with the dependency spider or other visualisation technique above this can often be the way to fix most inter dependency challenges.

The other thing I often like to do is team rotation. If you’ve got a fairly mature scrum team(s) you can often rotate one person from each team every sprint into the other team to help make visible potential technical dependencies. This requires quite a lot of discipline but can often work.

Metrics

Coupled with maybe some flow metrics, surface burndown & velocity show the impact of dependencies in & out of teams. This can be a powerful case for change & as a DM I’d urge you to consider bringing these results into reviews & project status updates to get stakeholders to resolve dependencies together.

People

I’ve been in a couple of situations recently where I’ve been asked about what would I do managing both complex up & down stream dependencies but also the people/stakeholders who often exacerbate the issues.

For me, you need to have whomever is working on the project properly connected & feeling a sense of ownership to the thing they are doing. I see too many projects where people are left to feel outsiders or don’t have enough connection to the very thing they are trying to manage.
There’s a great tool https://theliberatorsimproveyourteam.com/ that allows you to survey your scrum team & then understand actionable insights on how to improve as a group & this can be a really great start to ensuring collaboration & information exchange with different stakeholders.

Contextual Understanding

Above I talked about giving people a meaningful way to with which to connect to the thing they are managing. On a number of occasions where I’ve worked with C level folk in glass ivory towers or engineers at the non-user end of their product, bringing those worlds together really helps. Get people out on the front line, using, consuming & experiencing the products or services being enhanced, changed or transformed – this can be a really powerful experience that also acts to galvanise the team.

Practical Tools

I’m keen to always finish with practical tooling you can go away play with, consider & use for your dependency mapping exercise.

Ultimately, visuality is a thing so tools like;

• Monday.com (I love this tool & have rolled it out to quite a large team in an organisation)
• Mural
• Miro (my fav)
• Jira (look I know)
• Microsoft Project (please, honestly, )

There’s absolutely nothing wrong with baking dependency planning & visualisation into your tooling. Jira does a good job with its Planner component & the Early Access dependency view map https://confluence.atlassian.com/jiraportfolioserver/displaying-the-dependencies-map-1005805794.html which is well worth checking out if you have the appropriate subscription.

Microsoft Project is quite linear & pleasing in the way you can create waterfall neat & easy to understand dependencies but yes I know, its waterfall, we’re talking Agile but they can work together, I promise.

In Summary

Here are a few additional tips for managing dependencies in Agile projects:

• Use a tool to manage dependencies. There are a number of tools available that can help you to manage dependencies in Agile projects. These tools can help you to track dependencies, identify risks, and communicate with stakeholders.
• Create a dependency management plan. A dependency management plan is a document that outlines how you will manage dependencies in your project. This plan should include information on how you will identify dependencies, prioritize dependencies, sequence tasks, and communicate with stakeholders.
• Regularly review your dependency management plan. As your project progresses, you will need to regularly review your dependency management plan to make sure that it is still effective. You may need to adjust your plan as new dependencies are identified or as the project schedule changes.
• Be prepared for unexpected delays. Even with the best planning, there will always be unexpected delays in Agile projects. Be prepared for these delays and have a plan in place for how you will deal with them.

Managing dependencies is a challenge, but it’s an essential part of Agile project management. By following the tips above, you can effectively manage dependencies and keep your project on track.