Managing Dependencies in Scrum

A practical response

A dependency is a potential impediment. Some dependencies have an amazing power to consistently crush a team’s ability to deliver. We want to eliminate or minimize dependencies, but what if you can’t?

There are three general categories of dependencies that a scrum team will encounter, each becoming more challenging.

Intra-team dependencies

The least challenging dependency scenario is where a single team has all the skills needed to produce a completed and potentially deployable product backlog item (PBI). They have no external dependencies. They may still encounter either, a) PBIs that are dependent on each other, and/or, b) tasks within the sprint that are dependent on each other.

In either case, a self-managed team with excellent scrum master facilitation skills should be able to figure this out for themselves. For product backlog dependencies, developers make technical dependencies clear to the product owner, and the product owner uses this information to (re-)order the product backlog. For task dependencies in the sprint, developers are responsible to coordinate these tasks.

What might help:

Rework and decompose PBIs to be more independent of each other. This is best addressed before sprint planning in a product backlog refinement discussion, but may also be tackled during sprint planning.
In sprint planning, understand the potential risks created by dependencies and agree on how they will be handled. For example, the ability to decide between Path A or B for Item 2 cannot be made until Item 1 is complete. Monitor those dependencies closely during the sprint.

Inter-team dependencies

Next, and more challenging is the multi-team environment where more than one team is working from the same product backlog. Each team can consume and deliver product backlog items to their completion, but sequencing or technical coordination across teams might be required.

Without exploring various scaling models, start simple with self-managed cross-team coordination.

What might help:

Have only one product owner to minimize conflicting messages.
Ensure the product owner is working with the teams to understand how to distribute work. For example, giving all high priority items to Team A and lower priority items to Team B could result in lower value delivered if Team A falters compared to having both teams work on high priority items.
Elect one or two representatives from each of the dependent teams to be the ambassadors for their team. Those ambassadors take responsibility for coordinating with the other team ambassadors. That coordination can take place in what used to be called the scrum-of-scrums, a daily scrum that takes place after the usual daily scrum that’s designed for the ambassadors to discuss coordination matters with each other.
Extending the scrum-of-scrums concept, ambassadors can also coordinate before and after sprint planning and the sprint review.
Remember that the sprint review is open to any interested party, and members from dependent teams might be interested. Invite them to your review.

Related Articles:

Extra-team dependencies

Finally, the most challenging case is where a scrum team cannot complete all of the required work necessary to deliver a product backlog item. They need assistance or support from a) another scrum team, b) another department, or c) an external vendor.

Are those external areas aligned with agile thinking and are they practicing scrum? If yes, they understand expectations of the work environment, and you can align plans with them at the product backlog level. If not, and you cannot change that for now, the scrum team will need to plan their work around the external area’s schedules. Ensure that the hours required for dependency oversight are subtracted from the developer’s sprint capacity.

What might help:

Ask for delivery commitments from external contributors. Get specific dates and delivery expectations.
Stay on top of this. Invite external team representation to daily scrums. Verify frequently that the dependent area is still on schedule. Instead of checking for work progress, you may be better served by asking periodically, “are there any reasons you will not be able to meet your commitment?”
Retrospect on the external area’s performance. Were they dependable? Could you count on them to deliver what and when they said they would? If not, what will you do differently next time to mitigate your risk?
Finally, do not bring a PBI into the sprint if there’s an external dependency without an associated commitment of delivery. Since this is a business issue, the product owners should be fully involved and committed to providing any assistance needed in managing an external vendor or another department within your organization. product owners have bigger hammers that can be very effective if well aimed.

Remember, dependencies can destroy consistent value delivery. Do not assume that dependencies are just the way things are, but instead, view them as potential impediments and put the effort in to remove or mitigate their impact.

=======

About The Author

Peter Borsella

Peter Borsella is the founder of Winnow Management Corporation, established in 2005 and co-founder of Big Orange Square, established in 2017. In addition to being a Scrum Alliance Certified Scrum Trainer, he is also a Project Management Professional (certified by the PMI), and a Certified Large-Scale Scrum Practitioner (certified by The LeSS Company). His ability to train and coach across a wide range of environments has taken him from startups to internationals, from software to radar systems, and outside the United States to Taiwan, Israel, and Hungary.

RL_305_managing-dependencies-scrum