Managing Cross-Team Dependencies in Scaled Agile, From Planning to Real-Time Coordination | Christian Thordal

Summary

Podcast Summary: Managing Cross-Team Dependencies in Scaled Agile, From Planning to Real-Time Coordination

Podcast: Scrum Master Toolbox Podcast
Host: Vasco Duarte
Guest: Christian Thordal
Date: May 20, 2026

---

Episode Overview

This episode delves into the perennial agile challenge of managing cross-team dependencies in a scaled environment. Christian Thordal joins host Vasco Duarte to discuss practical strategies for identifying, tracking, and resolving dependencies during large-scale planning cycles. The conversation is grounded in real-world examples from Christian’s current organization—a large broadcast company—offering actionable insights and new experiments in dependency management.

---

Key Discussion Points & Insights

1. Scaling Up: From Team to Domain-Level Planning

Timestamps: [01:52]–[04:44]

• Christian emphasizes the importance of elevating the focus from individual teams to domain-level planning during quarterly (three-month) cycles.
• The main challenge: Lack of visibility and coordination on dependencies, both between teams and with sister domains, previously led to disrupted plans and delayed outcomes.
• Previous attempts at big-room planning did not yield desired results, prompting a shift to a simpler, more transparent approach.

“If one team had a problem or a plan that didn’t stick, the rest of the plan just fell apart... deliveries and deadlines, but also outcomes are delayed.”
— Christian Thordal [01:52]

---

2. Identifying Dependencies in Planning Frameworks

Timestamps: [03:17]–[05:07]

• Currently, dependencies are not formally addressed in the planning process.
• The Agile coach community is pushing for improved coordination, synchronizing planning cycles across domains.
• Main leaders now discuss cross-domain dependencies while setting OKRs; the expectation is that dependencies must be explicitly raised and communicated before commitment.

“Dependencies have been identified. They haven’t been handled yet. So when we see dependency as handled is when it is in the backlog of the team that needs to handle that kind of dependency.”
— Christian Thordal [04:47]

• Dependencies are considered “handled” only when they are visible on the backlog of the team responsible for resolving them.
• This approach aims to prevent blockers and keep work flowing.

---

3. Social Contracts vs. Planning Problems

Timestamps: [05:30]–[08:36]

• Vasco reframes dependencies as social contracts rather than purely technical or planning issues.
• Dependencies are not just “facts”; they are decisions made by various stakeholders.

“Dependencies are actually social contracts.”
— Vasco Duarte [05:38]

• Christian admits the conversation has so far been limited to identifying and acknowledging dependencies—more fundamental questions about whether dependencies are necessary or avoidable have yet to be addressed.

---

4. A Multi-Week Dependency Alignment Experiment

Timestamps: [06:33]–[09:50]

• Christian outlines a three-week planning cycle within his domain (32 total teams, 10 in his focus domain):
  • Week 1: Define OKRs
  • Week 2: Alignment (spot and clarify dependencies across teams/domains)
  • Week 3: Commitment (teams formally commit to resolving dependencies)
• The goal is explicit alignment before teams commit, minimizing the risk of becoming blockers.

“So the cycle we have: this week we define the OKRs. Next week is alignment, and that is why I needed the dependencies today. And the third week is going to be commitment.”
— Christian Thordal [07:23]

• Dependencies often stem from shared tech stacks (web, app, integrative technologies) that cross team boundaries.

---

5. Making Dependency Ownership Explicit

Timestamps: [10:05]–[12:30]

• Vasco suggests reframing each dependency as a “trio”:
  • The requester (needs the dependency)
  • The provider (solves the dependency)
  • The actual dependency (work item)
• Assign explicit ownership: One person is responsible for chasing the dependency; another is responsible for resolving it.
• This direct assignment allows real-time resolution, reducing the need for escalations and program management overhead.

“One person is the one who wants it—they chase, one person is the one who provides it—they report. And then there's the actual dependency… we can actually distribute to the rest of the organization the dependency management real time.”
— Vasco Duarte [10:17]

• Christian supports the idea, emphasizing the value of "huddles" (short, regular syncs) for those involved in resolving dependencies.

---

6. Two-Tier Dependency Management: People & Program

Timestamps: [12:30]–[13:37]

• Effective dependency management requires both team-level (people-to-people) and program-level (oversight/escalation) layers.
• Delegation to teams enables early detection and resolution without clogging the escalation chain.

“When we rely on the program management layer, the dependencies are always discussed too late because usually they are discussed after an escalation happens.”
— Vasco Duarte [12:47]

• Christian confirms this is the approach they’re currently experimenting with.

---

Notable Quotes & Memorable Moments

• Christian Thordal:
  • “If one team had a problem or a plan that didn’t stick, the rest of the plan just fell apart.” [01:53]
  • “Dependencies have been identified. They haven’t been handled yet.” [04:47]
  • “Cycle… week: define OKRs. Next week is alignment... third week is going to be commitment.” [07:23]
• Vasco Duarte:
  • “Dependencies are actually social contracts.” [05:38]
  • “Dependencies are not facts; they are decisions.” [08:09]
  • “One person is the one who wants it—they chase, one person is the one who provides it—they report.” [10:18]
  • “When we rely on the program management layer, dependencies are always discussed too late.” [12:47]

---

Key Takeaways & Experiments to Try

• Explicit identification and ongoing alignment on dependencies is crucial. Do not wait until commitment or escalation—surface issues early and often.
• Make dependency ownership visible. Assign specific people on each side of the dependency and empower them to coordinate in real time.
• Align planning cycles and OKRs across teams/domains. Enforce cross-functional syncs before commitments are made to avoid being blindsided by hidden dependencies.
• Experiment with short, regular "huddles" among dependency owners and stakeholders. Track progress together so issues never become blockers.
• Challenge dependencies as "decisions," not "facts." Foster discussions around whether certain dependencies can be avoided through team design or architectural choices.

---

Final Thoughts

Dependency management remains one of the toughest challenges in scaled agile environments. Christian Thordal and Vasco Duarte provide actionable tools and experiments for teams looking to move beyond reactive fixes into proactive, real-time coordination. The episode encourages listeners to reconsider how dependencies are surfaced, owned, and resolved—and to treat social contracts with as much care as technical solutions.

---

This summary covers only the content-rich discussion segments and omits all advertisement, introductory, and outro material for focused utility.

Transcript

[A]

Hey there, agile adventurer, just a quick question.

[B]

What if, for the price of a

[A]

fancy coffee or half a pizza, you could unlock over 700 hours of the best agile content on the planet? That's audio, video, E courses, books, presentations, all that you can think of. But you can also join live calls with world class practitioners and hang out in a flame war free and AI slop clean slack with the sharpest minds in the game. Oh, and yes, you get direct access to me, Vasko, your Scrum Master Toolbox podcast. No, this is not a drill. It's this Scrum Master Toolbox membership. And it's your unfair advantage in the agile world. So if you want to know more, go check out scrummastertoolbox.org membership, that's scrummastertoolbox.org Membership. And check out all the goodies we have for you. Do it now. But if you're not doing it now, let's listen to the podcast.

[B]

Hello everybody. Welcome to our Wednesday, the big challenge of the week. And this week we have with us Christian Tordal. Hey Christian, welcome back.

[C]

Hey Pascal. Thank you.

[B]

So as Scrum masters, we need to deal with a lot of complexity, human systems, lots of things happening at the same time. And obviously we are facing challenges all the time, but that's okay because we can explore those, learn, come up with ideas, run experiments and then get things better. And that's what we're going to try to do today, Christian. So let's explore a topic you have in mind. Can you explain the topic for us and then we'll, we'll dive into exploring that.

[C]

Yeah, I think this would be a great time to kind of elevate ourselves from teams to up to domain level. Right now we are planning our next cycle, meaning we plan what we're going to be doing for the next three months. And the issue or the challenge right now is that we don't have any grasp of the dependencies either between teams, but also to the sister domains that we have. And going back to the first cycle that we just concluded, that meant that if one team had a problem or a plan that didn't stick, the rest of the plan just fell apart. Which meant that the deliveries and deadlines, but also outcomes are delayed. So I think that's what we should talk about today.

[B]

Yeah, absolutely. And a topic that I'm sure many of our listeners are facing themselves right now because it is a topic that never goes away. How do we manage dependencies in a not so small organization? Right? Like if there's more than two Teams dependencies can already have quite serious consequences. So let's explore that topic. So obviously the first question that comes to mind is how are dependencies treated in your current planning framework?

[C]

Currently they are not. So what we we've done in the Agile coach community is we have raised this to the portfolio and delivery department, which is kind of where I am, I'm hired into and then I'm kind of borrowed out to the domain. So we've tried to sync with other domains on when are the cycles actually going? So you don't have any kind of, what do you say, diversion in that delivery time that you have. But I know the leaders of the portfolio and delivery have gathered all the product leaders and the domain leaders and have explained them. Then when we sync we also need to talk across domains. So everyone, it's kind of a big room planning without being big room planning. We did that a couple of years ago and apparently it didn't work. So we're trying more simple approach to it where the main leaders, when they present the okrs for the specific domains and teams within domain dependencies between domains have already been covered. And I communicated through the OKRs within the, within the, the domain

[B]

dependencies have been identified.

[C]

They've been identified. They haven't been handled yet. So how we, when we see dependency is handled is when it is in the backlog of the team that needs to handle that kind of dependency. And if you have a dependency to another team, your dependency is handled when it's in the backlog of the other team.

[B]

Okay, so it's almost like delegating the resolution of the dependency. I'm an interested party, but I'm going to put a task on your backlog because that's the task that signifies my dependency on you.

[C]

Yes, it's to make sure that it gets worked on so they don't become a blocker. Right?

[B]

Yeah, absolutely. When that is done, there's of course the step of identifying. But then the next step would be okay, but how do we get agreements on how we tackle it? And when we tackle it right, then the next step is the agreement which kind of highlights an important aspect of dependencies, which are, they are actually social contracts. Right. Because it's not a technical solution. It might also be a technical solution, but usually a dependency is hey, I need your API to do this thing and the other, which it doesn't do yet or does it wrongly now. Right, but that's just. Okay, that's the need, that's the requirement. Maybe there's a little Bit of technical details there, but really what we are trying to negotiate is a social agreement that I can depend on you to get this sorted out. Right. Is that how you see the teams looking at it as a social agreement, or are they looking at it more like a planning problem?

[C]

I think it started with a planning problem. So what we have done within my domain is that the teams that I'm responsible for, we've sat down and communicated the strategy and then we have looked into, okay, so what are the OKRs within our domain? And if the task that we're going to do, we don't have a PO, we have a PM, but he communicates his OKRs to the team. And then we started to look into, okay, if we're going to do this, what will hit us and who do we have dependencies to? So we've started to kind of scale it down to the teams within technology division, which I'm in. We have 32 teams and we have 10 teams within our domain. So we kind of did a small, big room planning or PI planning, if you want to figure out what teams are we impacting and who impacts us? And that's. So the cycle we have this week we define the okrs. Next week is alignment, and that is why I needed the dependencies today. And the third week is going to be commitment. So next week with the teams that we have, I have set up meetings to kind of figure out what are the scale of this and when do we need it.

[B]

Yeah, absolutely. Okay, so this raises another question that I wanted to ask, because dependencies are unfortunately sometimes understood as a fact. And in fact, when you think about it, dependencies are not facts, they are decisions. So have you guys been able to talk about that? Like, do we really want to have this decision? Is there a different way to tackle this? Do you go through this conversation already?

[C]

No, we haven't reached that point. Besko, this is an early stage of trying to fix just the bare minimum of getting teams and domains to align across.

[B]

Okay, and by alignment you mean preparing the commitment. Right? Like preparing the fact that I will say, yes, I will help you with that dependency.

[C]

Yeah, acknowledging the dependency and then actually commit so you don't block any of the other teams or domains work, because you might have the most serious consequence. You might have a team that would sit idle for a very long time and not really work on something valuable. But I think we are very interconnected with a lot of tools and different techs. It's a huge broadcast company that I'm within. So There's a lot of tech stacks also that we don't really do. My teams do. They do app and they do web and they interconnect with a lot of teams but are not responsible for all of it. So in all seriousness, they're dependent all the time, but it's definitely a should have.

[B]

Yeah. So what I hear you say is that we are starting to build the framework that would allow us to identify and explicitly decide how to tackle each dependency at the moment.

[C]

Yeah. So that's kind of the ambition for this goal. And that's what we're doing right now is the experiment. Right. So hopefully in week three, in two weeks from now, we will have that

[B]

alignment, which is, here's the thought from what you described. So let's say you're going to present the dependencies for commitment, right? Like there's been some identification, some, you know, understanding who can and how they can help with this dependency. How about just a thought, how about if we think about dependencies as a, how do you call it, a trio? Right? Like there's three concepts in a dependency. There's the person who wants or needs the dependency to be solved, there's the person who solves it, and then there's the what the dependency is. The reason why I mentioned person here is that one of the biggest problems with dependency management is the social problem, right? Like how do you even coordinate the solution to that dependency? And what we've done in the past, and this may be an idea to try out, is that what we've done in the past in some of my clients is that we explicitly name people for the dependency. So that one person is the one who wants it, they chase, one person is the one who provides it, they report. And then there's the actual dependency, because that way we can actually distribute to the rest of the organization the dependency management real time. Right? Like if we identify 10 dependencies and let's say that Alice and Bob are in one of those, then Alice always knows to ask Bob about the dependency. And we don't need to have another layer, let's call it program management layer, to chase every one of those 10 dependencies. Because we've now assigned that to the teams who can themselves talk to each other and get it solved real time. What do you think? Would something like that be possible?

[C]

Yeah, I think what we need to do so with the dependencies that we identify, for my sake, I think I've tried this one before, but I would like them to kind of huddle or have kind of A day during the cyc. So they would collaborate, connect, coordinate on the issues. Also to get some kind of report or status that you could then relay to your product manager that could relate to the product lead. Yeah, that kind of shows either progress,

[B]

because what I'm thinking is that there's two layers for dependency management, right? Like there's the people, people to people, or person to person layer, which is the person who needs it, the person who provides it, and then there's the program layer, so the person who oversees the work. And what I find, at least in my experience, is that when we rely on the program management layer, the dependencies are always discussed too late because usually they are discussed after an escalation happens. And what I'm thinking is for a large organization that has a lot of dependencies to handle, if we are able to delegate the day to day management of the dependency to the team level, we are more likely to get those, let's call it early warnings handled by the teams themselves without any need to go and raise it up through the command chain.

[C]

I think that's kind of what we're trying to do.

[B]

Awesome. Well, I hope this has been useful for our listeners. Dependency management is one of the most common things in software development and therefore a really important thing to run some experiments on and learning. And maybe we'll get Christian back in the future to tell us how this experiment went. So thank you for sharing that, Christian.

[A]

Alright, I hope you liked this episode, but before you hit next episode, here's the deal. This podcast is powered by people like you, the members who wanted more than just inspiration. They wanted real tools and real connection to people who are practicing agile. Every day we're talking access to over 700 hours of agile gold, CTO level strategy talks, summit keynotes, live workshops, E courses, Deep Dive interviews, books, and if you're into no estimates, we got the pioneers of no estimates in those Deep Dive interviews as well. Agile Business Intelligence, creating product visions, coaching your product owner courses, you name it. You'll get invites to monthly live Q&As with agile pioneers and practitioners, plus a private Slack community which is free of all of that AI slop you see everywhere. And of course, without the flame wars. It's a community of practitioners that want to learn and thrive together. It's the best place to connect with community and learn together. So if this podcast has helped you before, imagine what you will get from this podcast membership. So head on over to scrummastertoolbox.org membership and join the community that's shaping the future of Agile. We have so much for you. So check out all the details at Scrum Master Toolbox. Because listening is great. It's important. But doing it together, that's next level. I'll see you in the community.

[B]

Slack we really hope you liked our show. And if you did, why not rate this podcast on Stitcher or itunes? Share this podcast and let other Scrum Masters know about this valuable resource for their work Work. Remember that sharing is caring.