How do Scrum teams manage their dependencies on other teams?

Question

In a Scrum team, what do you do with stories that require work to be done by another team?

The work required of the other team could be well defined and in parallel: "We'll do this, and we want you to do that." Or it could be that we're asking the other team to engage with us in the development process - discovering requirements and impacts, planning, validating, and then delivering.

The team being autonomous requires that the team is trusted to deliver its stories within the sprint. So the team sizes its stories to the size it can deliver within one sprint, and then takes responsibility for delivering it. But when the team depends on another team, the other team may not start work at the same time, and even if it works efficiently, its work may end up crossing the boundary of a single sprint. If they are not efficient, their work, even though appropriately sized for a sprint, may not be delivered within the time of one sprint, for example if they have competing priorities and other work in progress.

It seems that by depending on another team, our team has lost its autonomy, and can't be trusted to, or held responsible for, delivering the stories. Can it still be called a Scrum team then? But surely Scrum teams do depend on other parties all the time? How should the team manage these dependencies?

Answer 1

A Scrum Team should be cross-functional, meaning that they have all of skills needed to deliver a valuable feature to completion, which ideally means production. This means that a Scrum Team nearly never needs another team to complete an item. However, there are two exceptions:

1) Even though your team might be able to deliver a valuable feature, other teams may be delivering related features so even though their work shouldn't be required for your team to successfully complete their feature, you still want to track it. A common way to do that is to have an over-arching board that tracks major feature sets or epics or whatever you want to call them. It can be a simple sticky-note board. For each large item, have a copy of the smaller parts that teams are working on next to in in a few columns - probably something simple like "Not Starting - In Sprint - Delivered".

2) Flukes - as much as cross-functional teams shouldn't have dependencies, it happens from time to time, but it should happen so infrequently that it really doesn't matter how you handle it. Write a note, wing it, whatever works for you. If it happens enough that the minor inefficiencies have an impact, you should be addressing the cross-functionality problem. If you're doing the first item anyway, that can be a convenient way to handle this circumstance.

A word of warning: Scrum is easy to game. If people are determined to split work and organize teams in the old paradigms, it's easy to use scrum terms and pretend to be agile, but you won't get the benefits out of it.

Answer 2

Scrum teams can encounter external dependencies, but as you rightly say they often adversely impact on the capability of the team.

I would recommend that every time a dependency occurs, the team asks the question: "What can we do to avoid this kind of external dependency happening?"

There are several ways this question might be answered, including:

• Is more training required?
• Does the composition of the teams need to change?
• Would knowledge transfer help?
• Do we need to be more careful with our planning?

When you do have external dependencies I would caution you against trying to manage them in a time-based fashion, by saying things like: "This story is a dependency for team X, so we need to complete it this sprint".

A better approach is to manage the dependencies using priorities. For example: "This story is a dependency for team X, so we are going to raise its priority".

This avoids falling into the trap of traditional development where ever more complicated plans are written in an attempt to avoid dependencies causing disruption. This is an anti-Agile approach as it restricts the ability of the teams to respond to change.

Above all, recognise that external dependencies are something we should work hard to avoid.