Dealing with dependencies

Chances are that if you are working in a company that has more than one development team or that is working on more than one product you have dealt with dependencies before. Dependencies are everywhere. And many times dealing with dependencies is a struggle. But it doesn’t need to be. Here are 3 tips on how to make dependencies less of a burden and to turn them around to your advantage.

1. Plan for dependencies

Ignoring dependencies is like thinking that the snow will never melt. You’ll be disappointed with all the rubble that was first covered by it when it starts thawing. Everything that was first covered is now there for you to deal with. But actually all those things were already there. The snow just made you ignore them.

The same goes for software development. Make sure you know what the other teams are working on. Even if they seem to be working on something completely different than what your team is doing: stay connected, stay in the loop. That way you will know beforehand if they are planning something that might affect you. Get familiar with other teams’ roadmaps and stay up to date on what they deliver every sprint. The roadmap will help you get a long term view, so you can already see if there are going to be touchpoints. And every sprint teams will report on what they have delivered and what they are planning in the next sprint.

Sounds like a lot of work? It isn’t. How long does a sprint demo take? Call in, or drop in to the meeting room every 2 weeks and you’re up to date. Even if that is too much work (because your company has so many teams, right) read the release notes, check the roadmap or occasionally have a coffee with somebody from the other team. It’s usually enough to get a taste of what is coming.

2. Turn dependencies into connections

Dependencies are only dependencies if they affect you negatively. Your team has to take time to work on something that doesn’t advance their goal. First of all: you’re all in this together. That other team is the same company. If you help them, you help the company. Second: the other team is asking your help because they are using something your team built that is of value. And they need that component because otherwise they would need to build it themselves. And that would be waste, which is of course to be avoided.

The fact that another team is dependent on your team creates a connection. Connections work both ways. It’s a good time to get your devs to work closer together, get familiar with each other’s codebases and maybe learn something in the process. Also, a lot of times new features are born after connecting with other teams. Dependencies are good, they confirm that you’re not working on an island.

3. Pay it forward

Don’t go all “quid pro quo” on the team that is asking for assistance. Remember: you are in this together. Do something nice for another team, without expecting something in return. It’s what you would do with your friends. Why not in business? More often than not the favor will be returned in the future. Also, paying it forward is infectious. Other teams will start doing it. Why? Because it feels good: you’re doing something good for other people, that you usually didn’t have to do and it is for the good of the company.

It doesn’t help that people will want to calculate the impact of one team on another team’s work. Some stakeholders will try this. Ignore them. OKRs, KPIs, and other so-called value-assessment techniques don’t work very well in an agile environment. Many have tried, many have failed. It’s a joint effort, you don’t need war heroes.

Dealing with dependencies is not useless. You need to, because there will always be dependencies between teams. So instead of closing your eyes and waiting for the storm to hit you, prepare for it, stay in the know and offer help, even before any is asked for. It will make you feel good, because you have done good. You will have saved a lot of time and you will have built bridges in the company. Start working together: death to all silos.