Skip to content

The importance of splitting teams (and how to)

Mathias PR Reding

You could say that I am a notorious team splitter. A fiery divider of teams, wherever I go teams end up separated. Team lumberjack could be my nickname.

Well, joking aside, whenever I think of the teams I made the best possible products with, that had the least amount of need for processes, where the most pro-active and most fun to work with, I have to say that those were the smaller teams. 

We have all seen them. Teams that seem to have no coherence and do not feel like a team. Instead of a team you see a group of people with different scopes or expertises that happen to be condemned to do the same meetings. Every day. More closely you could observe the following:

  • Sprint reviews with demo’s that go all over the application landscape,
  • Overly full backlogs where certain team members own specific subjects,
  • They have many different stakeholders with all their own specific part of a domain. Neither team and stakeholders seems to be happy,
  • A group of people that is very disengaged during the most team meetings,
  • Teams are unable to define a proper sprint goal,

For me most of those are a reason to, instead of trying to forcefully make the process work, start with the fundamental questions: what is your product vision? What is the purpose of this team?

Based on the examples I gave, the chances are high that it will be hard to state a single product  vision. You would see that team members have individual skills and scopes in regards to the organisation. And that is not a problem but it is important to make it explicit and take that as a starting point. 

We should strive to build teams around a vision or purpose instead of fitting products in a team based on capacity.

1: Logical grouping

The first step is seeing whether it is possible to group certain products/services so that they make sense from a user perspective.This group of functionality should have a single product vision, and can be delivered as a working product to users. 

Whenever a team is not responsible for creating products but are more supporting or guiding the organization and/or their customers often a product vision makes less sense. In this case a team purpose could be more clear and concise.

This product vision or team purpose will answer questions like: what will this product/service achieve, for who and why is that so important? This should be the main part of the team identity. This is where they stand for.

2: Forming teams

After clarifying the product vision and/or purpose it is time to ask team members to which vision or purpose they would want to contribute. After we have the preferences gathered we should collectively determine whether it is plausible. A tool that is very well suited for this is a skills matrix. 

This will provide an overview of what skills are needed to get an idea to end users and what skills and knowledge are available within the team. A validation of a skills matrix is the question “Can anyone go on an unplanned holiday?”. If not, what is needed to make this possible?

3: Finding the right processes

Work is often either plannable or unplannable. Based on the organizational needs the right way of planning should be picked. Is unplannable work inevitable, a framework like Scrum might just not work since predictability is one of the main results we want from that. 

How big is a team?

Part of the problem here is that it is often said Scrum teams should be between 5 – 9 people. Which is weird since we might be able to do the work with less people. Anyway, many teams nowadays are formed to be able to comply with that goal without considering the other way around. The best approach would be to form teams around features instead of the other way around.

In my experience multidisciplinary teams of 3-5 people work best and with every extra team member the process and number of communication lines grows. I will take a small team with a specific vision over any amount of resources and budget without clear objectives.