Three Teams, Three Backlogs, One Feature—Can You Make Them See Each Other? | Olaitan Fashanu

Summary

Podcast Summary

Episode Overview

Podcast: Scrum Master Toolbox Podcast
Episode Title: Three Teams, Three Backlogs, One Feature—Can You Make Them See Each Other?
Host: Vasco Duarte
Guest: Olaitan Fashanu
Date: June 24, 2026

This episode dives into the real-world challenge of fostering true synergy between multiple Scrum teams working in parallel on the same product, yet operating with separate backlogs—often leading to duplicated effort, miscommunication, and lost opportunities for collaboration. Olaitan and Vasco explore concrete strategies, lessons learned, and experiments for breaking down silos and building habit-forming cross-team collaboration.

---

Key Discussion Points & Insights

1. Defining Synergy Across Teams

• Challenge Articulated: Olaitan brings the issue of creating “synergy” between three teams working on the same product but each on separate backlogs dealing with the same, or related, features.
• “Synergy” Defined:
  • Olaitan (02:01): “How to ensure there is a shared understanding, there's collaboration between these three teams working on the same goal.”

---

2. Why Three Teams, Three Backlogs?

• Origins of the Setup:
  • Teams were split by leadership to move faster by focusing each on a “channel” (e.g., web, app, hub).
  • Olaitan (03:39): “These are decisions that were actually made at the leadership level...”
  • Not a deliberate intent to prevent collaboration, but a side-effect of focusing teams on specific product streams.

---

3. The Reality: Lack of Awareness

• Misalignment in Timing & Awareness:
  • Even if teams work on the “same” feature, they often start at different times or don’t realize others are tackling a parallel track.
  • Vasco (07:52): “Do they actually know that they are all working on the same feature or don't they know?”
  • Olaitan (07:59): “Sometimes they don't.”
  • Product Owners tend to have the overview, but developers may not realize cross-team overlap until late.

---

4. Steps Tried So Far: Synchronous Alignment

a. Product Owner Syncs

• Approach: Ensuring product owners align story priorities and timing in planning.
• Olaitan (08:28): “Work with the product owners to ensure alignment… [with] sync meetings ... to discuss what is coming up in the next sprint.”

b. Joint Refinement Sessions

• Approach: Bringing teams together for joint backlog refinement, so context is shared upfront.
• Olaitan (08:28): “We have introduced joint refinement sessions.”

c. Linking Stories Across Backlogs

• Try: Explicitly connecting tickets in different teams’ boards/tools, so developers can see cross-team connections.

• Olaitan (10:26): “I also encourage ... to actually link these tickets… [so] developers ... can actually brainstorm ideas on how to ... fetch data, etc.”

• Result:

  • Teams liked it and saw the value, but maintenance faltered—team members relucted to own the practice.
  • Vasco (11:28): “They want to, but they don’t want to do it ... That’s too much work.”
  • Olaitan (11:56): “They do say that.”

---

5. Experimenting: Surfacing Information, Building Habits

a. New Experiment Ideas

• Vasco Suggests: Periodically surfacing each team’s work at the start of every sprint.
  • Vasco (12:06): “What if we take a look at the other team’s backlog once at the beginning of the Sprint?”
  • Olaitan (12:14): “That’s a good idea, right?”
• Goal: Make this cross-team visibility a habit, lowering the “effort barrier” to collaboration.

b. The Real Agility Challenge: Making Collaboration Stick

• Even when an alignment experiment succeeds in the short-term and teams appreciate the outcome, maintaining that behavior as a recurring habit is the real challenge.
  • Olaitan (13:19): “How do you keep this as a habit for the team?... How do we maintain this habit?”
  • Vasco (13:39): “That’s a great question for the second experiment ... How do I make this stick so that I don’t need to bring it up?”

---

Notable Quotes & Memorable Moments

• On Leadership-originated Silos:
  • Olaitan (03:39): “I do not have the authority to influence in this area because these are decisions that were actually made at the leadership level to actually have these separate teams...”
• On the Shifting Maturity of Teams:
  • Olaitan (09:09): “…what I’ve noticed is that maturity level in teams actually fluctuates based on situations. So… if there are changes in that team, you will lose that momentum….”
• On Resistance to Ongoing Maintenance:
  • Vasco (11:28): “They want to, but they don’t want to do it.”
  • Olaitan (11:56): “They do say that.”
• Coaching Wisdom (Analogous from Weightlifting):
  • Vasco quoting a lifting coach (14:32): “The role of the coach: you find imbalance, you get rid of the imbalance. That’s it. That’s the whole loop. You find imbalance, you get rid of the imbalance, one by one, constantly. That’s how you get stronger.”

---

Timestamps for Important Segments

• [01:43–02:13] — Defining “synergy” in the context of multiple teams
• [03:20–04:19] — Why/how teams ended up with separate backlogs
• [07:52–08:07] — Teams’ lack of awareness about working on the same features
• [08:28–09:05] — Attempted solutions: Product Owner syncs and joint refinement
• [10:03–11:24] — Explicit linkage of stories and the role of Product Owners
• [11:28–12:06] — Teams like cross-linking, but don’t want to maintain it
• [12:06–12:34] — Habit-building experiment: “First sprint meeting, check all team backlogs”
• [13:19–14:22] — The challenge: making cross-team collaboration a habit
• [14:32] — Coaching wisdom metaphor

---

Key Takeaways

• Top-down team structures often unintentionally create silos, even if everyone wants to move faster.
• Team-level and Product Owner synchronization can improve awareness, but forming a sustainable, low-effort cross-team collaboration habit is the long-term solution.
• Surfacing information early—by routinely reviewing other team backlogs and linking related work—can make a tangible difference in aligning parallel teams.
• The real job of a Scrum Master or Agile Coach is to spot and remove such imbalances, then foster the practices so they become habitual and self-sustaining.

---

This episode provides thoughtfully practical advice, candid reflection on human resistance to “extra work”, and highlights the ongoing experiment-driven nature of Agile leadership.

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 warfree 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 the 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 coaching Wednesday, the biggest challenge of the week question with Olaiton Fashano. Hey, Olayton, welcome back.

[C]

Thank you so much for having me again.

[B]

Absolutely. All right, so Wednesday is the coaching conversation and we start by discussing a topic, something that you care about. It may be even a big challenge. So let's explore that topic together. What topic do you bring to us this week? Alaita.

[C]

Right, so the topic I'm actually bringing towards is how to create synergy between multiple teams working on the same products.

[B]

So let's define that a little bit more. What would you call synergy in that context?

[C]

So what I call synergy is how to ensure that there is a shared understanding, there's collaboration between these three teams working on the same goal.

[B]

When you think about that shared understanding, what is preventing that at the moment, in your opinion, from what you have seen, what is preventing this? Multiple teams, I don't know how many they are, let's say three teams. What's preventing those three teams, as an example, to have to experience that shared understanding?

[C]

Yeah. So what is if I could dig deep. So what is preventing me is that we have three teams working in different channels, working with, you know, they're working on different tenants, you know, and having different backlog. So having these three backlogs, no different backlogs. It's a way where people think of actually maintaining focus on their own, working inside, working on their own backlog instead of thinking of how that, how we can create synergy between the other team that actually working on the same feature.

[B]

So tell me a little bit more this is very interesting. So why would three teams, and I'm asking out of curiosity, how did it happen? Like why would three teams end up with three different backlogs if they're working on the same product? How did we get there?

[C]

Yeah, so I think this, we're going back to team topology right here. Yeah. So I think I would say that I do not have the authority to influence in this area because these are decisions that were actually made at the leadership level to actually have these separate teams to work on a feature that will be used by different channels. And then that was the top down decision for the teams to start working to figure out how to do that. But it's not. So that's was what happened. This was a decision that was taken by the.

[B]

Okay, so basically these teams are working on three different channels, which I guess you mean sales channels. So.

[C]

No, what I mean is that, you know, hub, web app. Web.

[B]

Okay. So customer interface channels like web and support, whatever, like something like that. So they're working on the same feature. Let's call it finding out why an invoice wasn't paid or whatever. Like we don't care. Yeah, some feature like that. And then they're using, they're. So they're trying to basically show the same information perhaps in different ways to someone. Maybe it's a CS rep, maybe it's directly to a customer, maybe it's an API, whatever that is. And they are deciding, meaning the teams are deciding to work on this and other features completely separately. Right. Like I'm working on my web, I'm working on my app, I'm working on my whatever, chat interface, whatever that might be. And what you're saying, if I got it right, is that their management decided you don't talk to each other, you're not allowed to even know what features you each other are working on, which may perhaps be the same, but may be different. Is that what they said?

[C]

No, no, no, that wasn't from the leadership team. No. So the leadership created these separate teams in a way to maybe to make things easier or to move faster for

[B]

one team, for each separate team move faster in each separate team. Right?

[C]

Yeah. To move faster. How do we ensure we move faster to customers? Both. But the thing is that even though if we're going to move faster, these teams actually sometimes are working on the same feature, the same thing, and at

[B]

the same time, if I understand correctly,

[C]

and at the same time. And so how do we ensure that these teams actually work together?

[B]

Okay, so tell me a little bit More. So tell me a little bit more. Do they know they're working on the same feature at the same time?

[C]

They do.

[B]

Okay. Are they aware of the possibility that they could help each other?

[C]

They. Of course they are aware.

[B]

Okay. Is that what you think or is that what they think?

[C]

This is what I think and this is what I know.

[B]

Okay. So how would you describe it from their perspective?

[C]

How I would describe it is that. Let me create a scenario here. Let me say something here that for example, this team is working on, like you said. Give an example of an invoice. I'm going to show data to a customer and then this team picks it up in this sprint that we want to work on this. Then the other team probably it's not even ready to actually pick up. Dax, that's that ticket to work, to work on. So once they pick that up, how do we ensure we create, you know, shared understanding? Or maybe, you know, we find, you know, communication or collaboration between these two things to ensure that they share understand of what to solve.

[B]

But then do they actually know that they are all working on the same feature or don't they know?

[C]

Sometimes they don't.

[B]

Okay, got it.

[C]

But I see that coming. So they know it's coming, but sometimes they are not aware when it's coming.

[B]

Okay, got it. So sometimes they know they're working on the same thing at the same time, but perhaps we can't assume that because sometimes they will not know. So we're trying to look at the situation. How do we make them aware that they are working on the same feature at the same time?

[C]

Yes. Okay.

[B]

What have you tried so far?

[C]

So what I've tried is to have to one is to work with the product owners of these teams to ensure that we have create alignment between these teams when to pick up these things. And then so we have this, you know, sync that we do that. We introduced that. Let's have this. Let's discuss what is coming up in the next sprint and then we prioritize that and then we align on that one is to who does what at what point. So we. So we're doing that. And another thing we've also tried is to have joint refinement sessions.

[B]

And so how have those worked so far?

[C]

They have been working for a team. But, you know, sometimes, you know, even when you say these things, you need to. The thing is, what I've noticed in that is that maturity level in teams actually fluctuates based on situations. So even if a team is mature at doing things so if there are changes in that team, you will lose that momentum, that maturity in that team. Yeah.

[B]

Or even if they are in a hurry, right?

[C]

Yeah, yeah, yeah. So these are sometimes. These are things that we can't actually predict, actually affects.

[B]

Okay, so does someone in this environment, in these three teams, does someone always know when they are actually working on the same feature at the same time?

[C]

They do. I would say the product owners, they know.

[B]

Okay, so we could try to work with the product owners to explicitly list the feature or story as, hey, this other team is also working on a similar story.

[C]

Yes.

[B]

It could be some kind of note at the top of the story description. This story is the same for team A, B and C. Yes.

[C]

Another thing that I do that I also encourage the product owners to do and even the developers to do is to actually link these tickets. If the other team has worked on this ticket or they're trying to work on this ticket, why not link this ticket to actually understand the context, not to actually get some. And then that would also help the developers to actually communicate better. A developer working on the same ticket and then you also, another developer working on the ticket, you guys can actually brainstorm ideas on how to actually where to fetch this data from, how to get this from somewhere, from that way.

[B]

That sounds like a great idea. So have you actually tried that? Like linking the stories or putting a textual note in the story description? Have you tried that?

[C]

Yes.

[B]

And how did the teams react to that? What happened in practice?

[C]

They actually love it. And they want that to be maintained.

[B]

They want to, but they don't want to do it.

[C]

Let me guess, they don't want to do it.

[B]

See, this is so cool because this is like one of those critical reflection points for us as Scrum masters, right? Like, we try an experiment. They love it. Meaning the teams, the team members, they love it. They think it's great. And then we say, okay, great. Now you maintain it. And they go like, no, we don't want to do that. That's too much work. I mean, I don't know if that's what they said. Just. Just brainstorming here.

[C]

They do say that. They do say that.

[B]

Okay, so. So this is so cool because this is one of those things that, hey, what if. And this is just an idea.

[C]

What if.

[B]

What if we take a look at the other team's backlog once at the beginning of the Sprint?

[C]

That's a good idea, right?

[B]

Like, it's okay. We don't force you to do anything. But what if in the first Sprint meeting, In the first daily standup of every Sprint, we just take a look at the stories the others are working on.

[C]

Yes, that's. I think that's. I've actually not worried about that. Yeah.

[B]

I mean, because the information surface. Right. Or surfacing information, rather. The surfacing of information is something we can always experiment with. And if that doesn't work, we could just randomly email something about the story to a developer in the other team and then when they say, oh yeah, that's not my story, but thanks for sending that. Now I know you guys are working on the same thing, right? Like it doesn't matter how the information surfaces. Of course we don't want to be the bottleneck. Right. Because we also want to go on vacation. So we need to figure out a technique that could work and maybe that habit, let's call it that habit of looking at the other team's backlogs could become a self reinforcing habit.

[C]

Yeah, exactly. I think the theme there, like you mentioned, is how do you keep this as a habit for the team? That is something that is always a thing that is actually difficult for me of maybe if, I don't know if it does the same with other Scrum Masters. How do we maintain this habit in the team?

[B]

Yeah, and that's a great question for the second experiment. Like after you do the, let's say first day of every Sprint review, then next experiment could be around. Okay, but how do I make this stick so that I don't need to bring it up? Right. Like, so that's cool. And that's the whole idea of how we work as Scrum Masters. Like we try things and then some work, some don't work, most things don't work, let's be honest. But that's why we need to try many different things and then when they work, we kind of learn and when they don't, we also. But then we move on to the next thing.

[A]

Right?

[B]

Like if. Oh yeah, the whatever, first day of sprint review works.

[A]

Okay.

[B]

How do we make it a habit?

[C]

Yeah, it's always the biggest challenge. How do you make it? Yeah, it's all, you know, how to keep that.

[A]

I have a phrase I heard from

[B]

a lift coach, a coach that helped me with lifting, and he always said the role of the coach, you find imbalance, you get rid of the imbalance. That's it. That's the whole loop. You find imbalance, you get rid of the imbalance one by one, constantly. That's how you get stronger. That's a great story.

[A]

Thank you.

[B]

For sharing that.

[C]

Thank you so much for asking.

[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

[B]

to people who are practical.

[A]

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.

[B]

So if this podcast has helped you

[A]

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 [e-mail] membership because listening is great, it's important. But doing it together, that's next level. I'll see you in the community. Slack

[B]

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 people, other Scrum masters, know about this valuable resource for their work. Remember that sharing is caring.