Effective teams through synchronous dependencies
Practical techniques and examples for collaboration in product development
When teams grow and multiple teams work on the same product, coordination becomes a crucial factor. However, coordination does not necessarily mean more processes or more management. The key lies in reducing delays and misunderstandings through spontaneous, informal and decentralised collaboration. The techniques presented here aim to maximise synchronous collaboration, i.e. working simultaneously, and reduce the complexity and delays associated with asynchronous handovers.
What is an (end-to-end) feature team?
An (end-to-end) feature team is a cross-functional and cross-component team that can independently deliver a complete customer-focused feature, from idea to deliverable product. This does not mean that the same team has to work on the same feature across multiple sprints.
Instead, the structure supports flexibility: teams can take on and continue work according to current priorities and availability, as the necessary shared understandings and integration practices are in place. Feature teams have all the necessary skills to deliver value without handovers or external approvals. They take technical and functional responsibility and are organised in such a way that delays due to external dependencies are minimised.
Importantly, a feature team focuses not only on features, but on delivering value to the customer by implementing end-to-end functionalities that contribute to meaningful outcomes.
But even well-organised feature teams do not work in isolation.
When multiple feature teams work on the same product, common goals, overlaps and a shared infrastructure naturally arise. This requires coordination. And while asynchronous dependencies such as handovers or written approvals should be avoided, teams must rely on synchronous collaboration to ensure rapid feedback, direct decisions and consistent product outcomes.
Why maximise synchronous dependencies?
Synchronous collaboration involves real-time interactions between individuals or teams, such as conversations, workshops, joint planning or spontaneous chats.
When I talk about maximising synchronous dependencies, I mean goal-oriented behavior by teams, as they consciously select related backlog items, ideally within the same parent topic or epic, so that they can work on overlapping or interconnected features during the same sprint. This coordination creates natural opportunities for collaboration, shared learning, and direct integration.
The goal is not to reduce independence, but to create intentional interfaces that improve shared understanding and adaptability. This leads to more frequent and meaningful interactions, mutual learning, and better coordination.
Feature teams want to maximise synchronous collaboration because it:
- Reduces communication delays and distortions
- Eliminates the need for coordination functions and intermediaries
- Promotes shared understanding and responsibility
- Accelerates learning and adaptability
In contrast, asynchronous collaboration, such as with tickets, emails or workflow tools, leads to handovers, waiting times, information loss and errors.
Synchronous collaboration does not mean more meetings, but the right conversations at the right time with the right people.
Overview of techniques for cross-team collaboration
| Technique | Description |
| A sprint (for all teams) | The feature teams all work in the same sprint rhythm with shared planning, reviews, retrospectives, and delivery. |
| Sprint planning (Part 1) | The teams coordinate at the beginning of the sprint: Who chooses what, what dependencies exist, and how are overlaps handled? |
| Refinement of the product backlog by multiple teams | The feature teams refine the items together: they clarify understanding, estimate the effort involved and divide up the work. |
| Communities | Voluntary cross-team groups on topics such as testing, UX or architecture for learning, coordination and joint improvement. |
| Direct cross-team communication | Team members communicate directly with each other without escalation chains, either in person, via chat or in mob sessions. |
| A shared product backlog | All teams access maximum transparency and prioritised collaboration on a single backlog. |
A sprint (for all teams)
All teams have a shared sprint with the same start and end dates. This enables coordinated planning, joint review and integrated increments.
Typical topics:
- A joint retrospective at the end of the sprint
- A sprint review for all teams at the end of the sprint
- Joint planning of high-priority backlog items for all teams
Sprint planning (part 1)
Teams meet at the start of the sprint to pull items from the backlog, agree on goals, and create transparency about what each team wants to work on, especially with regard to high-priority backlog items. Coordinating responsibilities is not the goal of this meeting; instead, coordination happens naturally during the sprint as teams identify overlaps or dependencies and communicate directly with each other.
Typical topics:
- ‘Who will take on payment integration?’
- ‘Team A and Team B both need the new API – who will start and how will we stay synchronised?’
- ‘How can we help each other, especially in terms of learning?’
Refinement of the product backlog by multiple teams
Multiple teams work together to refine the items in the product backlog; they break down items, clarify their purpose and deepen their shared understanding of the business area. The goal is to reduce knowledge gaps and increase adaptability by exposing more teams to a broader range of backlog items. This often involves direct interaction with customers or subject matter experts.
Typical topics:
- ‘What problem needs to be solved? / What is the desired outcome?’
- ‘How could we split this feature?’
- ‘What is the fastest way to achieve early value?’
Communities
Cross-team groups meet regularly to discuss common technical or subject-specific topics (e.g. test automation, architecture, UX), primarily for learning and knowledge sharing. Their main purpose is to promote research, deepen understanding and expand collective expertise, rather than to become decision-making bodies.
Typical topics:
- Learning new testing strategies from team examples
- Sharing experiences from recent architecture changes
- Exploring DevOps practices used in different teams
- Inviting internal or external experts to knowledge sessions
Direct cross-team communication
Team members make contact through ad hoc conversations, pairings or group debugging, for example, without going through roles or hierarchies.
Typical topics:
- ‘Can we work together on updating the CI pipeline?’
- ‘Let’s coordinate the API change, it affects both of us.’
- ‘We’re working on the same module. Shall we join forces?’
A shared product backlog
No separate team backlogs. A single product backlog with a product owner provides a shared view of priorities and goals.
Typical topics:
- ‘Should we move mobile onboarding up in the backlog, and does that fit 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 responsibility for prioritisation always lies with the Product Owner. Teams can and should make suggestions or contribute insights that influence the order of the backlog, but the decision is made by the PO.)
Questions and answers about feature team collaboration
Here are some practical questions and answers about feature team collaboration:
Where do we discuss improvements to the continuous integration pipeline?
Improvements can be discussed anywhere, for example during exchanges in a DevOps community (if available) or during joint retrospectives.
Tip: If necessary, improvements can be tracked by adding them to the product backlog.
Where are test strategies for different code areas (components) discussed?
Here too, anywhere is fine! They are most often discussed in relevant communities, e.g. in the testing community (if available) or the respective component community.
Who decides on technical standards such as logging frameworks or API conventions?
These topics can be discussed in relevant technical communities (e.g. architecture or backend). However, to ensure that the communities remain focused on learning and do not become decision-making bodies, it is preferable to make decisions elsewhere. Ideally, a small group of people from different teams should update the technical standards documentation on an ad hoc basis and communicate the changes to others.
Where do we clarify whether several teams want to change the same database structure?
If a team recognises the need to change a shared database structure, it can make the decision itself and inform the other teams. If it is unsure, it can collaborate with members of other teams, for example through pairing, direct communication or community discussions, and then share the results and updates with others.
Tip: Joint backlog refinement can help to identify such changes at an early stage, but the solution does not require formal coordination.
Where do we discuss the branching strategy for our repositories?
Branching strategies can be discussed wherever directly involved individuals meet. While a community (e.g., DevOps or engineering) can be a helpful forum for learning and exchanging options, decisions can also be made through informal collaboration, pairing, or joint discussions.
Tip: It is important that the branching strategy is transparent and well communicated.
Where is the shared Definition of Done maintained or updated?
Changes to the Definition of Done can be made in various ways, e.g. in retrospectives, through improvement initiatives or more comprehensive organisational adjustments. Since the Definition of Done is ultimately a measuring instrument, updates often originate from improvement discussions or from management. Documentation can take place where it is most visible and useful; a specific forum is not required.
How do we deal with errors in a specific component?
Each team can fix a bug in a component, regardless of whether it originally developed it. If a team notices a bug and can fix it, it should do so and learn more about the component in the process.
Tip: If responsibility or accountability is unclear, teams can clarify this directly among themselves or during refinement. In either case, the bug should be made visible in the product backlog to support transparency and possible follow-up actions.
Aren't there too many meetings?
By avoiding asynchronous dependencies, feature teams save time and energy by eliminating:
- Rework due to misunderstandings,
- Escalations and misalignments,
- Delays caused by waiting for responses,
- Confusion due to fragmented information.
Instead of extensive planning or subsequent corrections, synchronous techniques ensure rapid feedback and shared responsibility. They replace many unproductive status meetings, reports, and management loops.
What should we avoid when working across teams?
- Team-specific Product Owners: Leads to isolated backlogs and coordination problems.
- Separate team backlogs: Causes priority conflicts and a lack of focus.
- Coordination functions (project managers, team leaders): Treats the symptoms, not the causes.
- Coordination via tickets: Delays communication and accountability.
- Component teams: Enforces handovers and delays integration and learning.
Can you think of any other points?
Conclusion
Whether multiple feature teams are successful together depends less on additional processes or roles and more on how they work together. Where handovers, tickets and long waiting times dominate, friction and delays arise. Where, on the other hand, people talk to each other directly, spontaneously exchange ideas and develop solutions together, speed, understanding and quality increase. That is why it is worthwhile to consciously maximise synchronous dependencies and consistently minimise asynchronous friction. This creates genuine collaboration that advances products faster and better.
Notes:
Robert Briese is eager to hear your opinion and welcomes further thoughts on improving cross-team collaboration. If you are interested in further insights from him, sign up for the Lean Sherpas LeSSons Learned newsletter.
Would you like to talk about feature team collaboration as a multiplier? Then feel free to share this post with your network.
Robert Briese has published three more posts on the t2informatik Blog:
Remote sprint review in Large-Scale Scrum (LeSS)
4 big ideas to improve your sprint reviews
Advance your product backlog refinement
Robert Briese
Robert Briese is a coach, consultant and trainer in agile and lean product development and the founder and CEO of Lean Sherpas GmbH. As one of only 22 certified Large-Scale Scrum (LeSS) Trainers in the world he works with individuals, teams and organizations on adopting practices for agile and lean development as well as improving organizational agility through cultural change. He worked with (real) startups (Penta), Corporate Start-Ups (Ringier, Yello) and also big organisations (SAP, BMW, adidas) to create an organisational design and adopt practices that allows faster customer feedback, learning and a greater adaptability for change. He is a frequent speaker on conferences and gives regularly trainings in Large-Scale Scrum (LeSS).