🧭 Introduction
Picture this: Multiple teams, one product, one shared goal. On paper, it looks simple. But as development progresses, the friction creeps in, like delays, misunderstandings, repeated conversations, and work that needs to be redone. Not because people don’t want to collaborate, but because the way they're structured makes it hard.
More meetings get added. More roles emerge to coordinate. And slowly, without realizing, collaboration turns into a series of status updates rather than real joint problem-solving.
This guide is for those who want to break that cycle.
Instead of adding layers, we’ll look at ways to reduce friction through spontaneous, informal, and decentralized collaboration, with a focus on synchronous teamwork. These are practical techniques, not theoretical ideals. They’re designed to help teams working on the same product find real ways to collaborate in the moment, not after the fact.
This guide provides practical techniques for effective cross-team collaboration within a group of teams working on the same product. As teams grow and multiple teams work on a shared product, coordination becomes critical. But coordination doesn’t have to mean more process or more management. The key is reducing delays and misunderstandings through spontaneous, informal and decentralised collaboration. The techniques presented here aim to maximize synchronous collaboration - working together at the same time - and reduce the complexity and lag of asynchronous handoffs.
🌐 What is an “End-to-End” Team?
Before we dive into techniques for cross-team collaboration, it's important to understand one foundational element: team structure. The practices described in this guide only work effectively if teams are already structured in a way that enables autonomy. Without that, all collaboration becomes dependency management.
An “End-to-End” Team is a cross-functional, cross-component team that can deliver a complete customer-centric feature independently, from idea to shippable product. These teams include all the necessary skills to deliver value without handoffs or external approvals. They take technical and functional ownership and are organized to minimize delays caused by external dependencies.
In LeSS, those teams are called Feature Teams. Importantly, being a Feature Team does not mean focusing only on features. It means focusing on delivering customer value by implementing end-to-end functionality that contributes to meaningful outcomes. In other literature, like “Transformed” by Marty Cagan, those teams are called “Empowered Product Teams”.
Being such a team does not imply that the same team must work on the same feature across multiple sprints. Instead, the structure supports flexibility. Teams can pick up and continue work based on current priorities and availability, because the necessary shared understanding and integration practices are in place.
But even well-formed “end-to-end” teams don’t operate in isolation. When multiple teams work on the same product, shared goals, overlaps, and common infrastructure naturally arise. This creates a need for coordination. And while asynchronous dependencies like handoffs or written approvals should be avoided, the teams must rely on synchronous collaboration to maintain fast feedback, direct decisions, and coherent product outcomes.
🤝 Why maximize synchronous dependencies?
To avoid confusion, it is important to distinguish between two related but different concepts used throughout this article: synchronous dependencies and synchronous collaboration.
Synchronous collaboration describes how people work together: through real-time interactions such as conversations, workshops, joint planning, pairing, or spontaneous discussions. It is about direct human interaction without delays.
Maximizing synchronous dependencies, by contrast, refers to a specific team behavior (a term introduced by Bas Vodde in a talk at the LeSS Conference in Warsaw). It means that teams deliberately select related Product Backlog Items, often within the same higher-level theme, so that they work on connected problems during the same Sprint. By doing so, teams intentionally create situations where synchronous collaboration becomes both necessary and valuable.
The goal is not to reduce team autonomy or to force coordination upfront. Teams should be capable of delivering value independently. However, when multiple teams work on the same product, intentionally overlapping on related work creates natural points of interaction. These intentional intersections increase shared understanding, enable joint learning, and support direct integration when needed.
We want to maximize synchronous collaboration because it:
- reduces communication delays and distortion,
- removes the need for coordination roles and intermediaries,
- fosters shared understanding and joint ownership,
- accelerates learning and adaptability.
In contrast, asynchronous collaboration, such as coordination via tickets, documents, emails, or processes, introduces handoffs, waiting time, information loss, and avoidable errors.
Synchronous collaboration does not mean more meetings. It means enabling the right conversations, at the right time, between the right people.
🔧 Overview of Cross-Team Collaboration Techniques
Here is an overview of the key techniques that enable such cross-team collaboration in practice.
Technique |
Description |
One Sprint (for all Teams) |
All teams operate on the same sprint rhythm with shared planning, reviews, retrospectives, and delivery. |
Sprint Planning (Part 1) |
Teams coordinate at sprint start: who picks what, which dependencies exist, and how to manage overlaps. |
Multi-Team Product Backlog Refinement |
Teams refine items together: clarifying understanding, estimating effort, and splitting work. |
Communities |
Voluntary cross-team groups around topics like testing, UX, or architecture aiming for learning, alignment, and shared improvement. |
Direct Cross-Team Communication |
Team members talk directly to each other via face-to-face, over chat, in mob sessions, all without escalation chains. |
One Shared Product Backlog |
All teams pull from a single backlog in order to maximize prioritization, transparency and collaboration. |
🔍 Technique Details
One Sprint
All teams share a common Sprint with the same start and end date. This enables aligned planning, one shared review, and integrated increments.
🔹 Typical topics addressed here:
- Distribution of high-priority backlog items across teams in a (shared) Sprint Planning
- (One) Overall Retrospective at the end of the Sprint
- (One) Sprint Review for all teams at the end of the Sprint
Sprint Planning (Part 1)
The teams meet at the beginning of the sprint to pull items from the backlog, align on goals, and create transparency on what each team plans to work on, especially around high-priority backlog items. Coordination of responsibilities is not the goal of this meeting. Instead, coordination naturally emerges during the sprint when teams notice overlaps or dependencies and communicate directly with each other.
🔹 Typical topics addressed here:
- “Who’s taking the payment integration?”
- “Team A and Team B both need the new API. Who starts, and how do we stay in sync?”
- “How do we help each other related to learning?”
Multi-Team Product Backlog Refinement
Multiple teams collaboratively refine Product Backlog items by splitting items, clarifying purpose, and deepening shared understanding of the business domain. The goal is to reduce knowledge gaps and increase adaptability by exposing more teams to a wider range of backlog items. This often includes direct interaction with customers or domain experts.
🔹 Typical topics addressed here:
- “What is the problem that needs to be solved? "What is the desired outcome?"
- “How could we slice this feature?”
- “What’s the fastest way to deliver early value?”
Communities
Cross-team groups meet regularly on shared technical or domain topics (e.g. test automation, architecture, UX) primarily for learning and knowledge sharing. Their core purpose is to foster exploration, deepen understanding, and grow collective expertise, rather than becoming decision-making bodies.
🔹 Typical topics addressed here:
- Learning about new test strategies through team examples
- Sharing lessons learned from recent architectural changes
- Exploring DevOps practices applied in different teams
- Inviting internal or external experts for knowledge sessions
Direct Cross-Team Communication
Team members initiate contact directly, i.e. ad hoc conversations, pairing, group debugging, without going through roles or hierarchy.
🔹 Typical topics addressed here:
- “Can we pair on that CI pipeline update?”
- “Let’s sync on that API change. It affects us both.”
- “We’re working in the same module. Want to mob together?”
One Shared Product Backlog
No separate team backlogs. A single product backlog with one Product Owner provides a shared view of priorities and goals.
🔹 Typical topics addressed here:
- “Should we move onboarding for mobile up the backlog. Does it align with our current product goal?”
- “Does this feature align with our multi-market strategy?”
- “Are these the most valuable initiatives this quarter, based on what the Product Owner currently prioritizes?”
(Important: The accountability for prioritization always stays with the Product Owner. Teams can and should offer suggestions or raise insights that influence backlog ordering, but the PO decides.)
❓ Frequently Asked Questions about Cross-Team Collaboration
Where do we discuss improvements to the Continuous Integration pipeline?
Anywhere is fine! Common places include a relevant community (like a DevOps community, if it exists) or the Overall Retrospective. The important thing is that these improvements can be discussed anywhere and followed up by adding them to the Product Backlog when needed.
Where are testing strategies for different code areas (components) discussed?
Again, anywhere is fine! Most commonly discussed in relevant communities, such as the Testing Community (if it exists) or the respective Component Community.
Who decides on technical standards like logging frameworks or API conventions?
These topics can be discussed in relevant technical communities (e.g. architecture or backend). However, to ensure communities remain focused on learning rather than becoming decision-making bodies, it’s preferable to handle decisions elsewhere. Ideally, a small group of individuals from different teams updates the technical standards documentation ad hoc and communicates the changes to others.
Where do we clarify if multiple teams are about to change the same database structure?
If a team identifies the need to change a shared database structure, they can make the decision themselves and inform the other teams. If they're unsure, they can collaborate with members from other teams—through pairing, direct communication, or community discussions—and then share the outcome and updates with others. Joint backlog refinement can help surface such changes early, but resolution doesn't require formal coordination.
Where do we discuss the branching strategy for our repositories?
Branching strategies can be discussed wherever it makes sense, often by the people directly involved. While a community (e.g. DevOps or Engineering) can be a helpful forum for learning and sharing options, decisions can also emerge through informal collaboration, pairing, or direct discussions between team members. The key is that the approach is transparent and well communicated.
Where is the shared Definition of Done maintained or updated?
Changes to the Definition of Done can be raised in many ways, such as through retrospectives, improvement initiatives, or broader organizational changes. Since the Definition of Done is ultimately a measurement tool, updates often come from improvement discussions or management. Documentation can happen wherever is most visible and useful. No single forum is required.
How are cross-team technical debts identified and prioritized?
Technical debt can be identified in many ways, such as during regular technical reviews, shared backlog refinement, or through ad hoc team discussions. While teams should continuously refactor and improve code as they work, significant or recurring technical debt should be made transparent and added to the Product Backlog for visibility and prioritization.
How do we deal with bugs in a specific component?
Any team can address a bug in a component, regardless of whether they originally developed it. If a team notices a bug and can fix it, they should feel empowered to do so, and in doing so, they also learn more about the component. If the responsibility or ownership is unclear, teams can clarify this directly with each other or during refinement. In either case, the bug should be made visible in the Product Backlog to support transparency and potential follow-up.
🤔 Isn’t this too many meetings?
It might feel like more coordination—but in practice it’s often less.
By avoiding asynchronous dependencies, we save time and energy by eliminating:
- rework due to misunderstandings,
- escalations and misalignment,
- delays waiting for responses,
- confusion from fragmented information.
Rather than extensive planning or post-facto fixes, synchronous techniques create fast feedback and shared ownership.
They replace many unproductive status meetings, reports, and management loops.
🚫 What should be avoided? (Anti-patterns)
Team-specific Product Owners
Team-specific POs lead to siloed backlogs and coordination issues. When each team has their own PO, alignment across the product breaks down or becomes a coordination overhead. Teams end up optimizing locally, and the broader product vision suffers. Instead, one Product Owner should guide priorities across all teams working on the product, while each team is supported by strong Product Managers.
Separate Team Backlogs
Separate Team Backlogs cause priority conflicts, lack of focus, and reduced transparency. With multiple backlogs, it’s unclear what really matters most, and teams may drift apart in terms of purpose. A shared backlog ensures that teams focus on the most important work from a product-wide perspective.
Coordination Roles (Project Managers, Team Leads)
Coordination roles (like team leads or project managers) treat the symptoms, not the root causes. When coordination is offloaded to individuals instead of being embedded in team structures and behaviors, bottlenecks emerge. These roles often delay decision-making and reduce team ownership, instead of fostering direct, real-time collaboration.
Coordination via Tickets
Coordination via tickets delays communication and weakens accountability. Tickets are useful for work prioritization, but poor substitutes for conversation. If dependencies are managed through ticket queues, misunderstandings increase and resolution slows down. Real collaboration happens when people talk.
Component Teams
Teams with focus on technical components force handoffs and hinder learning. These teams specialize in narrow layers of the system (like frontend, backend, or database), but cannot deliver customer value independently. This creates long chains of dependency, makes integration harder, and reduces cross-functional learning.
