There are no hard and fast rules about how large an agile team should be. But there are plenty of opinions! Once you cross the mythical line and have 10 people on a team, do you have to split it? If you have two distinct tracks of work but only eight people, will you hurt efficiency if you divide and conquer?
The answer is… it depends. Over the last few years of experimentation and real-world applications, we’ve developed some “rules of engagement” about when it makes sense to break up a team. And then if you do, there are some factors we’ve found that greatly increase your chances of successful collaboration.
When to split teams
Psychological safety is undermined. Having too many people on a team can deter some folks (especially introverts) from participating. It’s easier to develop trust with a smaller handful of people you can really get to know well.
People can hide in the background. During meetings and working sessions, there’s just not enough time for everyone to have their say on a large team. But if there’s consistently a few folks not chiming in, then breaking up into teams can give them more room to be heard.
Multiple streams of work. When there’s two or more clear separations in the work, it can add efficiency to split teams (even for just a while) to tackle the different streams independently.
Tips for successful split teams
Identifying that you might want to split teams is only the beginning. To be successful, you also need to make a few things happen.
Reduce dependencies between teams. Each team’s work should be highly aligned, but loosely coupled. Teams should be able to work independently, ideally on different parts of the system, so there’s a clear division between work.
Minimize the potential for overlap. Consider having one backlog and refining it as a larger group, to ensure potential areas of overlap are identified early. This also helps the teams stay in the loop about what the other is working on.
Ensure each team owns something valuable. Everyone should have important work to do that adds value at every sprint. This helps avoid feelings of being ranked or being in competition between teams.
Plan for frequent communication across teams. Siloed information can cause rework. Ensure that each team has the info they need and knows when to who has the expertise they need to include.
Plan for variations in velocity. Make sure the product owner understands why the velocity may be different between the two teams — that it’s related to the differences in stories they’re working and not because one team is better or faster than the other. (Though if you do notice consistent differences in team velocity, it can be beneficial to look at the team dynamics to make sure you don’t need to adjust the team makeup.)
We’ve had several teams successfully split apart and come back together during the course of a project — mostly with great success. If you can identify when the team may start feeling “off,” it could be time to give your team a break.
