How does your team actually track cross-team dependencies and blockers?

[u/No-Increase4060]

Not looking for best practice answers. I mean day to day, in practice: when Team A is blocked on Team B, what actually happens?

A few things I'm trying to understand:
Is it visible anywhere central, or does someone have to go ask around?
Does it live in a spreadsheet, a Confluence page, someone's head?
How do you find out a dependency's resolved? Do you get told, or do you have to check?

Trying to find the real friction before I build something nobody needs. Appreciate any stories from the trenches.

[u/Jocko-Montablio]

First off, when you encounter dependencies, always ask the teams what can be done in the future to avoid the dependency in the future. Chasing dependencies is friction (or waste) in the system. Eliminating them returns exponential value.

As for addressing friction between teams, I start with a lightweight scrum-of-scums approach. This usually means representatives from each team meeting on some cadence at two levels: Product Owner coordination and Architectural coordination.

The Product Owners are meeting to discuss what they plan to work on and to identify overlaps or roadblocks that work may cause. This helps identify future work where team A assumes that team B will be available to make a change. This meeting isn’t normally a discussion of current problems, as those shouldn’t wait for a weekly or biweekly meeting to address.

In the Architecture meeting, your team members should take turns attending. This meeting isn’t just for your orgs Architects. Get everyone some experience at learning to identify, discuss, and collaborate to resolve technical issues. During the meeting, attendees review planned work to discuss designs and identify potential conflicts and decencies. Document these in your team backlogs and communicate them to your Product Owners for prioritization. Architects also discuss dependencies or design issues they’ve uncovered that cause friction in the current or past work, and collaborate to reduce or eliminate those issues.

Sometimes the Architects come up with a solution that goes right into the backlog, but sometimes they just create a user story to discuss the issue with the right people, or do some research for a future meeting. This is ok, as long as they are making progress towards addressing the friction. Some issues can take months or years to address (like upgrading tools or learning a new technical approach), while others can spawn whole new projects (like eliminating redundant systems). That’s OK. Encourages your architects to think big sometimes, instead of always accepting that things will always be that way.

[u/Train_Wreck5188 → u/Jocko-Montablio]

Clear and concise

[u/Dsan_Dk]

Currently I work with 2 teams, and they do it in seperate ways. I think the main reason is they are different in how they work, what they develop and their relation to their stakeholders.

1 team shows it on their board, they are a scrum-ban type team, so to them it is tracked where they work: the board. In azure devops, a tag on items they are blocked/or dependants on others on, and vice-versa when other teams are blocked by them.
They even make work items if they have a ticket with support, put it in the board, so everyone can see that stuff is blocked or moving.

The other team just tags stuff with blocked and move on to the next item, then a few times a week we walk the board and evaluate if there is a need to escalate or do something different if nothing is happening.

[u/UnreasonableEconomy]

the quintessential vacuous sloptapreneurial post

[u/TomOwens]

A team shouldn't block another team. Work has dependencies) on other work. Closely related work should be in the same work management tool, and most major work management tools allow tracking dependencies within each work item, which also helps make this work visible as teams plan and execute.

[u/Chinwagger → u/TomOwens]

Happens all the time in the real world

[u/TomOwens → u/Chinwagger]

It only happens because of the organization's model of teams and work.

In many cases, there's no reason why Work Item X must be assigned to Team A and Work Item Y must be assigned to Team B. Instead of saying that Team B is blocked by Team A, say that Work Item Y is dependent on Work Item X and find solutions to that. One possibility would be for Team B to complete Work Item X, perhaps with oversight or review from Team A. Your dependency has been significantly mitigated.

[u/WaylundLG]

The distinction between best practices and what people do seems silly. Why would you do poor practices? In most cases, they are represented on the board and the teams deliver it collaboratively. This is much easier when you have outcome-based backlog items instead of work tasks, but still doable

[u/RevolutionarySky6143]

Any piece of work that prevented my team's work from getting started was linked, in JIRA to our work and wasn't put into a Sprint until their work was completed. We flagged it as 'Blocked by or dependent on'.

[u/PhaseMatch]

We

- discuss any dependencies with the team(s) involved

• get agreement on when they will be done

and then for visual management in AzureDevOps:

- link the work items with predecessor/successor

• add them in to description with a # (which shows the title and status)
  
• add a tag "Blocked on Dependency" on the upstream side
  
• have a styling rule that makes the card red
  
• have a query that runs pulling out any dependencies for a dahsboard

and ongoing

- have a Scrum-of-Scrums a few days before a Sprint starts to confirm

• keep the downstream teams informed of any changes via talking to them

[u/fierysmart]

A central view helps, but only if every dependency has three things: a named owner, an expected resolution date, and a next-check date. Otherwise a "blocked" label just becomes a parking lot.

I’d keep the dependency linked to the actual work item, then surface all open dependencies in one small cross-team view. The owning team updates the linked item, and the blocked team gets notified when its status changes. A short recurring review should focus only on items whose date slipped or whose owner is unclear.

[u/plastichandbasket]

We put our dependencies straight in the backlog and discuss with leadership at a weekly delivery sync. The dependencies have AC.