🧭 Introduction
Imagine the following scenario: multiple teams, one product, one common goal. It sounds easy on paper. But in the course of development, points of friction creep in: delays, misunderstandings, repeated discussions and rework. Not because the parties involved do not want to work together, but because the existing structure makes this difficult.
More and more meetings are being added. More and more roles are being created to take over coordination. And slowly, without anyone realizing it, the collaboration is turning into a series of status reports instead of real joint development.
This guide is for anyone who wants to break this cycle.
Instead of introducing additional layers, we show ways to reduce friction through spontaneous, informal and decentralized collaboration, with a focus on synchronous collaboration. It is about practical techniques, not theoretical ideals. They help teams working on the same product truly collaborate in real time.
The guide presents proven practices for effective cross-team collaboration in product groups. When teams grow and multiple teams work on a common product, coordination becomes critical. But coordination doesn't have to mean more process or more management. The key is to reduce delays and misunderstandings through direct, spontaneous and informal collaboration. The techniques presented aim to: Maximize synchronous collaboration, i.e. working together at the same time, and minimizing complexity and delay through asynchronous handovers.
🌐 What is an “end-to-end” team?
Before we go into concrete techniques for cross-team collaboration, a structural foundation is crucial: the team structure. The practices described in this guide only work if teams are structured in such a way that they can work independently. Without this basis, every collaboration becomes dependency management.
An “end-to-end” team is a cross-functional and cross-component team that can implement a complete, customer-oriented feature independently, i.e. from the idea to the deliverable product. These teams have all the skills needed to deliver value without handoffs or external approvals. They assume technical and technical responsibility and are organized in such a way that they avoid delays due to external dependencies.
In LeSS, these teams are called feature teams. Important: A feature team does not only focus on features, but on Delivering customer value through complete end-to-end functionality. In other literature, such as “Transformed” by Marty Cagan, these teams are referred to as “Empowered Product Teams.”
Such a team doesn't necessarily have to work on the same feature over multiple sprints. Rather, this structure allows flexibility: teams can start or continue work depending on priority and availability, as there is the necessary common understanding and integration.
But even well-established end-to-end teams don't work in isolation. When multiple teams work on the same product, common goals, overlaps, and shared infrastructure automatically arise. This creates a need for coordination. And although asynchronous dependencies such as handoffs or written approvals should be avoided, teams must rely on synchronous collaboration use to ensure quick feedback, direct decisions and a coherent product.
🤝 Why maximize synchronous dependencies?
To avoid misunderstandings, it is important to differentiate between two related but different concepts used in this article: synchronous dependencies and synchronous collaboration.
Synchronous collaboration describes the way people work together, e.g. through real-time interactions such as conversations, workshops, joint planning, pairing, or spontaneous coordination. It's about direct human interaction without delay.
Maximize synchronous dependencies On the other hand, describes specific team behavior (a term introduced by Bas Vodde in a presentation at the LESS conference in Warsaw). It means that teams consciously related product backlog items select, often within the same overarching topic, so that they work on interrelated issues during the same sprint. As a result, teams create targeted situations in which synchronous collaboration necessary and valuable will.
The goal is not to reduce team autonomy or to force coordination in advance. Teams should always be able to deliver value independently. But when multiple teams work on the same product, targeted overlaps in related work lead to natural points of contact. This intentional overlap promotes shared understanding, enables learning and supports direct integration when needed.
We want to maximize synchronous collaboration because it:
- reduces communication delays and distortions,
- eliminates the need for coordination roles and intermediaries,
- promotes common understanding and shared responsibility,
- accelerates learning and adaptability.
In contrast, asynchronous collaboration, such as coordination across tickets, documents, emails, or processes, results in handovers, waiting times, loss of information, and avoidable errors.
Important: Synchronous collaboration doesn't mean more meetings. It means: The right conversations with the right people at the right time.
🔧 Overview of cross-team collaboration techniques
Here is an overview of the key practices that enable 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. |
🔍 Details of practices
A (joint) sprint
All teams work in a joint sprint with the same start and end dates. This enables coordinated planning, a joint review and an integrated increment.
🔹 Typical topics covered here:
- Distribution of highly prioritized backlog elements across multiple teams in a (joint) sprint planning
- (A) joint retrospective at the end of the sprint
- (A) joint sprint review for all teams at the end of the sprint
Sprint planning (part 1)
The teams meet at the start of the sprint to draw entries from the backlog, coordinate goals, and create transparency about what the teams are working on. The aim of this meeting is not coordination of responsibilities. Instead, coordination during the sprint is achieved through direct communication when there are overlaps or dependencies.
🔹 Typical topics covered here:
- “Who starts implementing payment integration? ”
- “Team A and Team B both need a new API. Who starts and how do we stay tuned? ”
- “How can we help each other learn? ”
Multi-Team Product Backlog Refinement
Several teams work together to refine product backlog entries by dividing them up, clarifying their purpose, and building a common understanding of the domain. The aim is to close knowledge gaps and increase adaptability by confronting more teams with a wider range of backlog entries. This often includes direct interaction with customers or subject matter experts.
🔹 Typical topics covered here:
- “Which problem should be solved? What is the desired outcome? ”
- “How could we edit this feature in a meaningful way? ”
- “What is the fastest way to achieve initial added value? ”
Communities
Cross-team groups meet regularly on common technical or technical topics (e.g. test automation, architecture, UX), and especially to learn and share knowledge. Their main goal is to promote exploration, deepen understanding, and expand collective expertise instead of forming decision-making bodies.
🔹 Typical topics covered here:
- Explore new test strategies using examples from the teams
- Sharing insights from recent architectural changes
- Investigation of DevOps practices used by different teams
- Inviting internal or external experts to share new ideas
Direct cross-team communication
Team members get in touch directly, e.g. through spontaneous conversations, pairing, joint debugging, without taking roles or hierarchies into account.
🔹 Typical topics covered here:
- “Can we coordinate on this CI pipeline update? ”
- “Let's coordinate the API change. It affects both of us. ”
- “We work in the same module. Do we want to bully it together? ”
A shared product backlog
No separate team backlogs. A joint product backlog with a product owner ensures a common view of priorities and goals.
🔹 Typical topics covered here:
- “Should we move mobile device onboarding up the priority list? Is this in line with our current product goal? ”
- “Does this feature fit with our multi-market strategy? ”
- “Are these the most valuable initiatives this quarter based on the product owner's current priorities? ”
(Important: The product owner is always responsible for prioritizing. Teams can and should make suggestions or provide insights that influence the order of the backlog, but the decision is made by the product owner.)
❓Frequently asked questions about cross-team collaboration
Where are we discussing improvements to the continuous integration pipeline?
Wherever it makes sense! Common places include a relevant community (such as a DevOps community, if available) or the overall perspective. It is important that these improvements are made visible and, if necessary, included in the product backlog.
Where are test strategies for different areas of code (components) discussed?
Here too, the following applies: wherever it fits! This often happens in relevant communities such as the testing community (if available) or in the respective component community.
Who sets technical standards such as logging frameworks or API conventions?
These topics can be discussed in the appropriate technical communities (e.g. architecture or backend). However, to ensure that communities focus on learning and do not become decision-making bodies, it is advisable to make decisions externally. Ideally, a small group of people from different teams will update the technical standards documentation as needed and communicate the changes to the others.
What to do when multiple teams want to change the same database structure?
When a team recognizes that a change is necessary, it can implement it independently and inform others. In case of uncertainty: pair with other teams, communicate directly or discuss in a community. Joint refinements help to identify such issues early on — but formal coordination is usually not necessary.
Where is the branching strategy being talked about?
Wherever it makes sense — often directly from the people concerned. Communities like DevOps can help you explore options. Decisions are also often made through direct collaboration, pairing or conversations. Transparency and good communication are important.
Where is the common Definition of Done maintained or updated?
Changes to the Definition of Done can be initiated in a variety of ways, for example through retrospectives, improvement initiatives or more comprehensive organizational changes. Since the Definition of Done is ultimately a measurement tool for the organization's adaptability, updates are often made as part of improvement discussions or by management. Documentation can be done where it is most visible and useful. There is no need for a specific forum.
How are cross-team technical debts identified and prioritized?
Technical debts can be identified in a variety of ways, for example as part of regular technical reviews, joint backlog refinements, or spontaneous team meetings. While teams should continuously improve their code, significant or recurring technical debts should be made transparent and added to the product backlog to make them visible and prioritize.
How do we deal with bugs in a specific component?
Any team can fix bugs, regardless of which team originally caused them. If a team can identify and fix a bug, they should do so while learning more about the component. If responsibility is unclear, the teams can clarify this directly among themselves or during refinement or sprint planning. In any case, the error should be made visible in the product backlog to ensure transparency and enable possible follow-up.
🤔 Isn't that too many meetings?
It may feel like more coordination, but in practice it often is lesser.
By avoiding asynchronous dependencies, we save time and energy by eliminating:
- Rework due to misunderstandings
- Escalations and misalignments
- Delays due to waiting for answers,
- Confusion caused by fragmented information.
Instead of complex planning or subsequent clarification, synchronous techniques enable quick feedback and joint responsibility.
They replace many unproductive status meetings, reports, and management loops without additional overhead.
🚫 What should be avoided? (Anti-pattern)
Team-specific product managers
Team-specific product owners lead to isolated backlogs and coordination issues. When each team has its own product owner, coordination across the entire product suffers or leads to increased additional coordination efforts. The teams ultimately optimize locally, and the overall product vision suffers. Instead, a single product owner should set the priorities of all teams working on the product, while each team is supported by competent product managers.
Separate team backlogs
Separate team backlogs result in priority conflicts, a lack of focus, and less transparency. With multiple backlogs, it's unclear what's really important, and teams can diverge on their goals. A shared backlog ensures that teams focus on the most important tasks from a product-wide perspective.
coordination roles (project manager, team leader)
Coordinating roles (such as team leaders or project managers) address the symptoms, not the causes. When coordination is delegated to individuals rather than integrated into team structures and behavior, bottlenecks arise. These roles often delay decision-making and reduce team ownership instead of promoting direct collaboration in real time.
Coordination via tickets
Coordination via tickets delays communication and weakens accountability. Although tickets are suitable for prioritizing tasks, they are not an adequate substitute for a personal conversation. When dependencies are managed via ticket queues, misunderstandings increase and problem resolution slows down. Real collaboration comes from direct exchange.
Component teams
Teams focused on technical components force frequent handovers and hinder learning. These teams specialize in narrowly limited system levels (such as frontend, backend, or database), but cannot generate customer benefits on their own. This results in long chains of dependency, makes integration difficult, and reduces cross-functional learning.
