How to manage dependencies in Scrum

Scrum teams are supposed to be independent of anyone outside of the team and be able to create a Done Increment every Sprint. But how realistic is it?

In a big organization, many processes and workflows would create dependencies for a team, whether you like it or not.

In this post, I’d like to share some thoughts on what to do when your team finds itself at odds and gets stuck due to something (or someone) outside of their control.

Here I’m sharing a short clip from a mentorship call I felt had enough useful information to warrant a dedicated video and a blog post.

How to plan a Sprint when there’re dependencies

If the team has a lot of dependencies, most likely they will want you to be a point of contact for helping resolve those dependencies, making sure that the other team is aware of those dependencies.

So that if we need something from another team, we plan for it. We let them know and we get whatever we need from them at the time we need it.

That would be kind of managing the relationships with other teams and helping your team to plan properly for those dependencies. Let’s make sure that we actually plan it out, that we estimate the wait time, and whatever that may be.

What can the team do if they plan a Sprint and they understand there will be a bottleneck where they will have to wait for another team to deliver something? What can Scrum Master do in this case?

Say we’re in a Sprint Planning, and if I know that there’s a high dependency rate, or I hear that there is some dependency, I generally recommend the team to first of all think: will we be able to get this out of the way during this sprint and complete this item?

Most of the time, the answer is “no”.

99% of the time the team says: well, no, we need to actually resolve it before we can even start thinking about this work item.

In this case, what you take into the sprint is not the work item itself, but what you need to do to resolve it. For example, we need to follow up with the other team.

Here’s the latest date when we want them to deliver this item to us. And so for you, as a Scrum Master, it’s more about making sure the team actually takes on the work that they realistically can complete.

If they think they will not be able to resolve this dependency immediately, in the first couple of days, then it means that instead of taking the work that is right now blocked, we’ll take this work once we unblock it.

Questions to ask your team

You should be asking questions about the dependencies, like:

• are we waiting on someone?
• is there something that is blocking us?

Usually, the team sees when they are planning if there may be a dependency.

It’s just that they sometimes don’t think about it.

They say: well, this is blocked, but we’re still gonna take it.

As a Scrum Master, you may say: okay, we can take it, but we need to still talk about it. We can’t just say, oh, it doesn’t matter.

What can Scrum master do if there is an impediment or a cross-dependency?

The question here is: would it be usually developers who go ahead and try to communicate with other departments or is the Scrum Master doing that?

And I think it depends on the situation, and what exactly is needed.

Often it may be very technical, for example. And if it is, then it makes more sense for the developers to take it over, because otherwise, you will be just a third person in the middle trying to transfer the information.

Whatever that is you want to facilitate the communication. It may be that your team has been sending requests to the other team forever, for two weeks, and they still didn’t get a reply.

Well, you can maybe have more leverage if you talk to the right people.

As a Scrum Master, you can say: okay, team, you can keep doing your work, and I’m gonna try to take care of this impediment and figure it out on my own. I’m going to go speak to the Product Owner. Maybe I’m gonna go speak to the manager of this team.

You’re trying to find ways to get this resolved and in this, in these cases, your team is not wasting time on these things.

What I as a Scrum Master can do to make it more efficient if they have a bottleneck with testers?

What kind of challenges they’re facing and where you would need your help?

It’s very possible that the team, and the developers work faster than the QA. I think often developers only plan for the development.

So they take on the work that they think they can complete, and they never actually think about the work that QA needs to complete.

But just the development work without the QA, that’s not good enough.

We need both to actually be completed. And it’s very possible that the team has a lot of carryovers, so they take on new work while the previous is still not done.

For example, in every sprint planning, they’re say that they can *totally* deliver a hundred story points. They take it all in, but then in the end, they are only able to deliver 60. And then the carry over, just never ends.

And that can be very frustrating for the Product Owner because they cannot really plan ahead and they most likely need to manage these expectations with the stakeholders.

The solution will depend on how the teams are organized.

Coaching your team on cross-functionality

And this is actually exactly what is happening right now with the teams I’m working with.

They had kind of two teams of developers and a third team of QA. They have developers working on their own and QAs working on their own.

As a Scrum Master, you would want to create a cross-functional team and much more collaboration so that the developers and QA work together. It means that when we are planning in Sprint Planning, we have both developers and QAs. And we also discuss and estimate the efforts of the QA, not just the devs.

Because as simple as that, people just forget about it. The QA is not there and that’s it, the devs already forgot that there is QA involved.

Even after a few months, the teams I work with had a challenge thinking about the fact that there is QA and they have a limited amount of time they can actually use to complete the testing.

That’s kind of one of the things to make sure that that communication channel is open.

Then another thing is actually working with the devs more, coaching them on that concept of cross-functionality and the fact that it’s not about your task and you finishing your task. It’s about the team.

Did the team deliver the item?

You may have completed your coding – great! But if the team was not able to deliver anything because the QA didn’t understand your code, well, that’s still on you.

Because we are focusing on the team goals, not individual goals.

And this is where the Scrum Master needs to do some coaching to help people just change how they perceive their work, and how they perceive their team, and help them focus more on those team goals rather than individual goals.

That’s kind of more of long-term personal development for the developers that the Scrum Master can help with.

Addressing the underlying reasons for slow delivery

Maybe you just don’t have enough QAs. Like that might be just as simple as that.

This is the problem and the company needs to either hire more people or accept the fact that they can only deliver half of what they want.

Because you are limited on QAs, this is where you might also need to work as a Scrum Master with the Product Owner and stakeholders to set the right expectations.

You may even need to bring in some metrics to show what the team can realistically push through QA in one sprint.

When you bring in metrics you can say what should be used when the roadmap is created.

Another thing that can be done is to see how do developers work with QAs? Do they collaborate?

Maybe there is an opportunity for the developers to help QAs. Yes, they will not be as effective, or efficient, they’ll be slower, but in the end, by helping QAs, they will be able to deliver more.

Because they will be helping QAs it means that the actual completed work will increase, and we only really care about what’s fully Done.

That can be another coaching opportunity: challenging the devs and seeing how they can help QAs and limiting the amount of work they push through the workflow, through QAs.