Don’t Split the Team Until You Have To

If you have a team that is unable to work effectively, there could be any number of causes. If you’re thinking about splitting the team into two or more teams as a way to solve the problem, my advice is to fix the root cause of the problem instead.

Splitting the Team

There are various reasons for wanting to split up a team.

Team Too Big

The ideal Agile team size is 5-8 people. If you have more than that, you are likely experiencing ineffective team communication, long stand-ups and bottlenecks around the product owner and designer.

Splitting the team may actually put more strain on communication in the form of cross team meetings and emails. Likewise, stand ups may be shorter, but you may need to go to more than one. Splitting the team would also require an additional product owner the designer to relieve the bottleneck. Going without either is not ideal. Neither is having someone splitting their time between two teams.

A more direct solution would be to simple decrease the size of the team. Move an engineer to another team.

Too Many Products or Product Owners

If you have multiple products or product owners, you might experience frequent shifting between projects. Engineers may feel that they are not able to focus on a problem for long, before they are pulled onto something else. Overall velocity may suffer.

You could split up the team along product or product owner lines. Make sure not to end up with teams that are too small. If you only have one or two engineers on a team, you will be subject to wild swings in team velocity when one or both people go on vacation, or are sick. You are likely going to struggle to provide healthy levels of code review and mentorship from engineers who have enough context on the work. Finally, you lose the ability to flex resources and swarm everyone on one task if the need arrises.

Another solution would be to reduce the number of products the team is working on, and funnel the product backlog through a single product owner.

Prioritize Technical Work

Product owners are naturally going to prioritize feature work. If the team is not getting the time they need to invest in technical platform and refactoring, you may be experiencing instability in production, and what should be small code changes resulting in much more work than expected, or frequent regressions.

Splitting the team so that one group can focus on platform work will result in getting more of that work done. But there are non-obvious downsides that go with it. It will be difficult to keep the two teams in sync about what projects are going on. Both teams may feel that they don’t get to do as much of the product or platform work as they would like. The two teams may start to drift in their alignment on technical solutions.

A better solution in this case would be to come to an agreement to reserve the time for platform work in the team’s normal sprints. A common ratio is 20% of team velocity.

Empire Building

Maybe you have a technical lead who wants complete ownership of a certain component. Maybe you have some who wants to to manage people, and you need a team for them to manage. Or a manager who wants to manage multiple teams. These are all terrible reasons to split up a team.

For technical projects, you need to find a way for people to have ownership regardless of team makeup. For people interested in management, this is probably a negative signal about whether they are a good fit for management. But just wait a while, there will always be more organic opportunities for that.

Other Stuff

Keep in mind that by splitting the team, you’re creating a potential dependency for future projects. Dependencies are productivity killers. Don’t take that too lightly.

Final Word

You want to avoid splitting up a team until you absolutely have to. You should prefer moving people to other teams versus splitting the team. Make sure you’re solving the root cause of your problems.