Ask Women in Product: How do you manage Scrum for multiple teams within the same cycle?
Answer from Lilia Gorbachik, Product Manager at Intermedia
This article assumes you have a basic understanding of the Scrum framework. You can learn more at scrum.org
The first thing to do when faced with the challenge of managing multiple Scrum teams is to understand the structure of the teams you need to manage. Scrum is a framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value.
What does this mean? Since Scrum is a framework, there is no predefined picture. You never see two identical teams in two different companies. The way teams are organized inside the company is tailored to the needs of their product and organization. Because everything is important — how teams communicate, which roles are centralized in a separate team, which artifacts they use independently or share across teams — all these separate details need to be considered in a management process.
Ideally, Scrum works with one team:
But what if you have multiple teams? In this case, you also need to deal with the complexity while doing your best to preserve all the benefits that Scrum provides.
The First Case: several small Scrum teams
In smaller companies, you’re likely to have small teams of up to 6 people, with developers, quality assurance (QA), UX designers, and a Product Owner (PO) in each team. This case is closer to the iconic Scrum, and it’s easier to build this type of team in a small company. Teams like this easily act as one system — one heart beating. In this case, using one sprint size and a common sprint start date for all teams is the best solution because it synchronizes the teams in the organization. Synchronizing the teams also makes it is easier to deploy a solution and launch new products. Small, self-organizing teams can handle communications between themselves without any defined process, which is wonderful.
Product owners maintain one product backlog that is used as the source of tasks and they also take care of splitting the company backlog to create team backlogs. Product Owners also communicate the scope of priorities to all teams to promote alignment.
Other Scrum artifacts and ceremonies that each team manages independently are the daily standups, sprint planning, demo, and retrospective. However, holding a common retrospective once in a while is a good idea.
The Second Case: mixed types of teams
A more complex case from the product owner’s point of view is that of a larger company with a more diverse product portfolio.
In some organizations, teams of developers, QA engineers, and product owners operate separately and on different cycles than UX designers and analysts. While this structure could be used to keep the product together, you need to do more work to reduce the risk that the product could break into pieces instead of being solidly integrated.
Complexity increases dramatically in this second case because instead of one beating heart, you have a complex system that needs to be synchronized and connected. Consider an organism attempting to walk; each leg should move not by itself but should act as a part of an organism that is synchronized with other legs. As you can see in the picture below, the number of communication channels runs pretty high, which means that the overhead of coordination could slow down the company when it comes to releasing the product.
To stay focused and on track with your product goals, you need to have clear communication channels for help and feedback from your UX and analytics team members to avoid creating a bottleneck in your product development process. By decreasing the size of the UX and analytics teams you might have more flexibility.
Take our sample organization that has three Scrum teams: Tigers, Foxes, and Lions. These Scrum teams have two-week sprint cycles. Their UX and analytics counterparts follow one-week sprint cycles. In this structure, POs and Scrum masters become key communication points.
Each team backlog should be viewable by any team interested in it. Information should be transparent and available. Openness in this area reduces stress and builds trust.
Let’s take a look and see which Scrum artifacts are useful to share across teams in this second case.
- Common product backlog. It is great to have a common product backlog. It helps keep goals and priorities clear.
- Separate sprint backlogs. Each team has a separate sprint backlog to work with. The team-specific backlog will set clear goals for the team and make their scope visible. At the same time, it is useful to see if the individual task has a linked task in another team.
- Separate burndown charts. Keep this chart per team, because each team tracks their progress individually inside the group.
- Common Retrospective. We work based on one product–one goal, so having a common retrospective for multiple teams is a good idea. A common retro can be a place for larger discussions, such as which forms of communication work and which do not. Also, common retros will allow everyone to feel attached not just to their team, but to the company and product as well.
The Third Case: loosely-coupled, tightly-aligned teams
There is a third team structure that you may be working in, one that has been popularized by Spotify. In this structure, each team acts as an independent business unit within the organization. At the same time, other virtual units are created that connect people based on other properties, such as:
- a feature
- the platform (mobile app, desktop app, etc.)
- the technology
- an idea (security, scalability, etc.)
- a department (front-end development, QA, back-end development)
This framework is no longer Scrum-compliant, but it is still Agile in that Agile is a more common concept, while Scrum is a specific, well-defined framework. Even if you step away from Scrum, you still could be Agile and gain benefits from it.
While the specific terms for a unit is not so important, the terms that have been popularized by Spotify are Squad (the team), Tribe (a lightweight reporting matrix), Chapter (people in the same tribe who share a competency area but belong to different squads), and Guild (a community of interests for sharing knowledge about a competency area across tribes).
The main idea behind this framework is to create as many communication channels as are needed to pursue one company goal. The more teams you have, the more difficult it is to keep the company’s and teams’ goals aligned. In this case, the Product Owner is the key person for keeping everyone moving in the same direction. In addition, all teams should be aligned from the product, design, technical, and even tools perspective. Sounds challenging, right?
If the company’s goal is well defined, then the goal can be broken down into sub-goals for teams. Each team will solve their part of the puzzle the best way possible, asking other teams if needed. Also, it doesn’t matter when each team starts their sprint and how they plan their work in this type of organization. What matters instead is the result.
Sharing best practices between teams becomes crucial in an organization like this — spreading the best ideas, supporting one another on tools, reusing best practices — when everyone is learning from everyone else and agreeing on the best way to do things, the company moves faster.
If you need to further customize the frameworks above because of a specific need or limitation, simply keep the following set of principles in mind:
- You will always need to rely on a role or goal or principle around which all work is organized. Everyone needs to know what that organizing principle is so that teams are aligned as they make progress on their respective backlogs.
- The communications channels are tailored to each specific configuration because you want there to be enough flows of information for teams to stay in sync, but not too much that people are spending time on non-essential busywork.
- Consider the best use of each Scrum artifact for your particular scenario and decide if they should remain at the team level, or if they should be shared across teams.
- Finally, never stop sharing best practices and lessons learned, so that everyone keeps getting better together.
I hope this answer helps you find the best path forward for your team and company. Good luck!
Answer from Stephanie Muxfeld, Consultant at Slalom
This is a great question! In a perfect world, product managers would always be aligned with a single team and a single product. In the real world, however, we sometimes get spread across multiple products. I’ve also seen products so large that they needed multiple teams, aligned to the same product manager. The good news is that different team structures have the potential to be successful at producing a quality product.
As with many things involving agile and product management, the answer depends on the team and the situation. To tackle this question, we’ll look at the question from a few different angles.
- Team Setup
- Backlog Management
- Stakeholder Management
- Technical Considerations and Tools
Why are there multiple Scrum teams? Is it a case where you are the product manager over different products, or is your one product so large that you need multiple teams?
In both cases, you’ll need to consider the impact on your schedule:
- Are the teams using the same sprint start and end dates? If so, how is that working for the teams? It can be a challenge for a product manager when multiple teams have ceremonies on the same days, but not impossible.
- Can the teams conduct their ceremonies at different times of day, so that you can attend both? The advantage with this is that you get all your ceremonies done, with the rest of the sprint left for you to divide your time between your two teams.
There is no reason why you can’t succeed as the product manager for two different products at the same time, but you’ll need to prioritize organization, documentation, and dedicated time with each team to succeed.
You will also need to grow your ability to change contexts (products) on the fly, as your teams need you. But being organized and taking excellent notes can make this much easier.
What’s the situation with the backlogs? Do the teams have separate, distinct backlogs? Are both teams pulling work from a single backlog?
In most situations, it is imperative that each team have a unique backlog that they own, without dependencies, so they can pull work as they are able without coordinating with another team.
If you are in a situation where two teams share a single backlog, I’d recommend looking for ways to split them up. If the teams are working on the same product and you cannot reasonably split the backlog, having a combined planning session is likely your best bet.
Consider sharing showcases as well. I am a firm believer that retros should always be team-specific, but in the scenario where teams are working on the same product, it can be helpful to occasionally hold combined retros. The communication between the two teams is critical to avoid them working on top of each other.
What are the expectations of your stakeholders? How involved are your stakeholders in the day-to-day work of your team? Do stakeholders require your teams to be on the same start date, have a shared showcase, etc.?
The best-case scenario would be that our stakeholders let our teams determine their own way of working, and focus solely on results. However, I’ve heard enough stories about overreaching stakeholders and I’ve also experienced them first-hand. If your stakeholders are dictating things that your team should be deciding for themselves, I suggest taking a hard look at where you can push back on the stakeholder.
Sometimes stakeholders are used to dictating to their teams, but if you push back and make your case for the team being self-directed, it may turn out in your favor. Sometimes our stakeholders need to be educated about the value of self-directed teams. And then other times they will not relent, and you have to manage that and protect your team from the distraction. I find stakeholder management to often be the hardest part of being a product manager!
Technical Considerations & Tools
Are your multiple teams working in the same code base? If so, do they have a defined branching and merging strategy? What is your approach to QA/testing and fixing defects/bugs?
If you have two teams working on the same product, you must work with your engineers to ensure they have a strategy to avoid working on top of each other.
They will, at a minimum, need an approach for branching and merging that will allow them to work together while not driving each other crazy. You’ll also need a strategy for production deployments. Can each team deploy independently, or do they need to coordinate deployments? Are they going to test each other’s changes? It’s always better to develop working agreements on these topics before it’s time to push to production!
Do you have a backlog management tool that you use? If so, that’s great. Learn it inside out and make it work for your team. I’ve also managed backlog successfully using a tool as simple as a spreadsheet. The specific tool is irrelevant, as long as it works for your team!
You Can Do This!
If you are the product manager for multiple teams, you can absolutely drive success for both your teams and your product(s). While it usually isn’t an ideal situation, you can — with proper organization, documentation, and time management — deliver awesome products while having some fun along the way!
Use these resources to learn more
- One Product Manager, Four Teams? by John Cutler (Hackernoon)
- Synchronize Rather than Overlap Sprints by Mike Cohn (Mountain Goat Software)
- How to set up multiple Scrum teams working on the same set of Master User Stories within a Project (Atlassian Community)
Thank you to Sara Nofeliyan for editing this piece.
You may also like Ask Women in Product: What’s the best way to handle a micromanager?
Sydney Russakov and Sara Vienna offer practical tips to strengthen your working relationship with your (micro)manager.