Collaboration with up to three teams can be coordinated easily, but the challenge starts once you grow beyond that. Don’t panic — there are some simple solutions that can help you.
A common mistake PMs and product leaders make is deploying a scaling framework immediately after passing the three-teams threshold. You’ll cause more problems than solving them — scaling frameworks will add processes you don’t need, which will get in the way of collaboration.
I don’t want to diminish the scaling challenge, but I want to help you understand how to simplify it. That’s where scrum of scrum comes in.
You may be tired of scrum already and don’t want to consider this option, but please stick with me for five more minutes — a scrum of scrums isn’t scrum. It’s a way of collaborating effectively with multiple teams.
In simple words, a scrum of scrums is a collaborative meeting between the involved teams on a project. It is an engaging session that keeps teams aligned and in the know with each other.
When scaling teams, you will face the following challenges:
Scrum of scrums aims to solve all of these with simple exchanges by team representatives working on the same product.
Suppose you have seven teams working on the same product. Getting everyone in the room to deal with dependencies and other details is unproductive.
With scrum of scrums, each team delegates the responsibility to one team member, and the exchange happens with seven people instead of dozens in this example.
Honestly, I dislike the name “scrum of scrums” because it connects directly with scrum. That’s misleading. You can use scrum of scrums with any framework, like, scrum, Kanban, LeSS, etc.
As you likely know, scrum is an agile framework with its own set of rules and ceremonies. Though it can be implemented and modified to fit an organization, scrum’s practices are pretty set-in-stone. The scrum of scrums, as I mentioned, can be applied to any project management framework.
The essence of scrum of scrums is not to change the original framework, but to enhance communication and collaboration between multiple times. So, despite its name, scrum of scrums doesn’t equal scrum itself — it’s a valuable add-on that helps us overcome the challenges of scaling.
When it comes to how you set it up, you won’t find a well-defined way that fits everyone. You’ll need to figure out what works best for you.
My two cents: focus on the problem you want to solve and organize your sessions accordingly.
The standard way of having scrum of scrums is the following:
The above format is simple and productive. It doesn’t overwhelm team members with meetings.
You will face a dilemma of who should attend the scrum of scrum meetings and who should moderate them. This discussion can get quite heated and lead to poor results. Let me help you avoid that.
Step back and reflect on what you want to solve with scrum of scrums. Products are different — some are more technical and some are not. Depending on your scenario, a technical person may be the best choice to represent the team, but in other scenarios, the product manager may be the best fit. You’ve got to identify what works best for you.
I don’t recommend skipping this decision and ending up in a situation where you have a tech scrum of scrums and a product one. This will for sure create silos. Believe me; you don’t want that.
It’s okay to alternate who attends the session. That’s a team decision to nominate the representative. Just try it out and learn from the results.
When it comes to moderation, scrum of scrums tends to require little moderation when done well. I’ve seen teams acting autonomously well. But, in other scenarios, an agile coach or scrum master was necessary to keep members focused on the session and address the relevant issues.
An effective scrum of scrums keeps your teams aligned and reduces dependencies. To reach that, team members need to talk about problems they face related to the collaboration.
Let me first tell you what not to do:
The best practices I recommend are the following:
Scrum of scrums is flexible and you can use it in combination with any framework and organization size, but some aspects will vary.
Effective communication has its limits. If you have 30 agile teams, getting a scrum of scrums session with 30 people won’t be helpful to anyone.
We have a limitation of people we can collaborate with and still connect the dots. I’d suggest limiting it to seven people. Otherwise, communication becomes ineffective. But what do you do with 30 teams, then?
With several teams working on the same product, you need to slice the responsibilities well. It’s impossible to have everyone working on everything. A better way is to split the product into several areas.
To make it easier to understand, let’s take a marketplace product. You could start separating by sellers and buyers. Then, you could again separate by acquisition, activation, and retention. That way, you’d have multiple units of scrum of scrums, each dedicated to specific topics. Each topic would have a maximum of seven teams working on it.
Organizing teams and prioritizing collaboration are essential because everyone suffers when that fails.
Most teams I’ve seen could benefit from having the product manager as the team representative for the scrum of scrums. Now, let’s clarify how product managers can make the session valuable.
Using the right tools will boost your productivity to make the most of scrum of scrums. Although I said that you don’t need much moderation, in a remote session, you’d need a minimum of preparation. Here’s my recommendation:
Keep it simple and focus on bringing progress to your team. Remember, the goal is to remove obstacles and dependencies.
Scrum is simple and valuable. You can get the most out of it when you ensure the minimum structure is in place and limit collaboration to seven teams.
In some situations, you will realize that teams are tightly coupled, and you’d be forced to run scrum of scrums with 10 or more teams. This will be ineffective. Please, step back, and help the organization reorganize the teams to enable effective collaboration.
Scrum of scrums isn’t a silver bullet for collaboration, but it’s a booster. Therefore, teams must address issues directly with each other when they are blocked. They should not wait for scrum of scrums if they are blocked and cannot progress.
“Teamwork is the ability to work together toward a common vision. The ability to direct individual accomplishments toward organizational objectives. It is the fuel that allows common people to attain uncommon results.” — Andrew Carnegie
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Nick Fisk shares his experience leading transformations and transitioning companies to a product ownership model.
It’s easy to hide behind charts and justify decisions with shallow metrics. But great product teams resist that urge.
Tony Schumacher shares important lessons he learned and has taken with him from working under his former boss and mentor.
Using these guidelines, you can ensure that you develop lean, functional, and valuable products — all while avoiding feature creep.
Learn more →
