Skip to content

Scaling teams and managing dependencies (Part 2)

In a previous article I wrote on 12 best practices for scaling teams and managing dependencies. I used the insights from SAFe, LeSS, NEXUS and Spotify. In this article I will focus on ownership, visualisation and cross team and external dependencies.

Ownership of dependencies

The topic of ownership is an interesting topic. Talking with senior managers the discussion on the owner looks like looking for the single neck to grap when something goes wrong. From team perspective ownership can determine how naturally a team will engage in resolving dependencies.

Teams should ultimatly own dependencies (Best practice 13). The team commits to deliver and if they are depending on other teams or 3th parties this is part of the deal. If dependencies become impediments the Scrum Master or the Release Train Engineer can facilitate to resolve the dependencies. In complex environments sometimes Program Managers also get this role to manage dependencies on behalve of teams.

Visualising dependencies

The charm of the program board in SAFe is to visualise dependencies. This helps during a PI Planning Event. During a PI it can become difficult to track the progress based on progress of the team backlogs. The excel showed in the first article can help.

NEXUS uses coloured arrows to show the type of dependency (Best practice 14). This helps in determining if the dependency is based on resource, knowledge or tasks. Team can use the type of dependencies to resolve them. Knowledge dependencies can be mitigated by providing additional training or knowledge sharing. Blue arrow 6 represents a high risk dependency because depend on each other in the same sprint.

I think the arrows can be effectivily used during the elaboration of and during a sprint. It could be a nice experiment to use it on a program board in a PI planning Event.

Cross team and external dependencies

The Spotify approach states cross team dependencies outside of the tribe should be investigated closely and resolved with changes in the organisation, architecture or solution. Sometime mocking can help resolving in the beginning. If these external dependencies become structural cause for teams not delivering escalation only will not work. Inevitably a one roof approach in with the 3th party team and depending team work together will be required.


In this 2 articles 14 best practices have been explained to manage dependencies. Ultimatly teams own dependencies in order to deliver their commitments. It’s up to senior management to enable teams to be as autonomous as possible, and make courageous decisions on minimizing dependencies that are blocking or slowing a squad down.

Leave a Reply

Your email address will not be published. Required fields are marked *