A couple of years ago, I was invited to speak at a few Agile conferences about my experience with LeSS (Large-Scale Scrum). The talks went well. People nodded, took notes, and clapped politely. But once the sessions ended, the real questions started. Not the theory ones. The practical ones. “One Product Owner for many teams? How does that even work?” “One Scrum Master handling more than one team, won’t everything slow down?” “Aren’t dependencies the Scrum Master’s headache anyway?” Honestly, fair questions. I had the same doubts before I lived through it.
Reality
About 5 years back, I joined as an Agile Coach. Roughly 120 people, multiple Scrum teams, one product. We aimed for something close to LeSS, though we adapted as we went. And yes, dependencies showed up. Everywhere. We tried the usual things first:
- Better backlog refinement across teams
- Joint sprint planning
- Cleaner stories
- Stronger engineering practices like ATDD and Continuous Integration
It helped. A lot. But dependencies didn’t magically disappear. At some point, we stopped fighting reality and accepted a simple truth: In large products, some dependencies will always exist. So instead of pretending they shouldn’t be there, we focused on handling them better.
What Actually Worked?
Scrum of Scrum but not really
We knew Scrum of Scrums can easily turn into a boring status meeting. So we renamed it, “Chai Pe Charcha.” Thirty minutes a day. Open invite. No compulsory attendance. Did it solve everything? No.Was it useless? Also no. It helped surface issues early. Sometimes that’s enough.
Walk. Talk. Repeat.
This one sounds obvious, but it worked better than any meeting. If you’re blocked, walk over. Ping someone. Talk. If you don’t know who to talk to, ask your Scrum Master or a teammate. No process beats a real conversation. This reduced dependencies faster than any framework tweak.
Weekly Informal Fridays
Every Friday, two hours. No slides. No pressure. Initially, this came from complaints: We don’t know what other teams are doing. Over time, it became a space to:
- Share experiments
- Discuss failures (yes, openly)
- Learn what worked and what didn’t
Surprisingly, visibility improved without adding dashboards.
Let the Code Speak
Processes help, but engineering practices do the heavy lifting. We leaned hard on:
- ATDD
- Continuous Integration
- Working on a single mainline
- Feature toggles instead of long-living branches
When code integrates daily, dependencies lose their power.
Skills gaps were a hidden dependency. So we tried something simple: travelers. A developer from Team A temporarily joins Team B to help, learn, and unblock.No permanent transfers. No HR drama. Just people moving where they’re needed most.
About One PO and One SM for Multiple Teams
This is where theory scares people. In reality?
- A Product Owner doesn’t attend every discussion, teams talk directly when clarity is needed
- A Scrum Master doesn’t “solve” dependencies, teams do, with support
When teams mature, coordination becomes shared responsibility. This is something we also explain clearly in HelloSM sessions, especially for professionals coming from traditional project management backgrounds. It’s one reason many learners call HelloSM the best Scrum training institute in India, because it talks about how things actually work, not just how the guide says they should.
Dependencies don’t kill agility. Silence does. When teams talk, move, share, and integrate continuously, even a 100+ people setup can feel surprisingly light. No magic frameworks. Just humans working together, imperfectly, honestly, and better every sprint.
Frequently Asked Questions
How do multiple Scrum teams handle dependencies without getting blocked?
Dependencies don’t disappear, even in Agile teams. The key is to spot them early. Teams do this during shared backlog refinement and planning. After that, regular conversations help more than meetings. Developers talk directly to other teams, integrate code frequently, and raise issues as soon as they appear. Strong practices like Continuous Integration and ATDD also reduce last-minute surprises.
Can one Product Owner really manage multiple Scrum teams?
Yes, it’s possible, but only if teams are mature. The Product Owner doesn’t need to attend every discussion. Teams are encouraged to talk directly when they need clarity. The PO focuses on product vision, priorities, and value. This setup works well in large environments and is commonly explained in practical courses like HelloSM, often considered the best Scrum training institute in India for real-world learning.
Is resolving dependencies the Scrum Master’s responsibility?
Not really. The Scrum Master supports the team, but dependencies are a team responsibility. Developers coordinate with other teams, ask for help, and resolve blockers together. The Scrum Master only steps in when the team is stuck or needs organizational support. This shared ownership makes teams faster and more confident.
What practices help reduce dependencies in large Agile teams?
Good engineering habits make the biggest difference. Working on a single code branch, using feature toggles, integrating code daily, and writing tests early all help. Beyond tools, simple things like walking over to another team, weekly informal catch-ups, and shar