Don’t split people across agile teams
Why do people get split across agile teams?
People sometimes get split across teams when working agile (or Waterfall, for that matter). You might hear things like “this team has two front-end developers, two back-end developers, a UX designer, a tech BA, and 50% of an architect”. Why 50%? There are usually two reasons:
The team doesn’t need a full-time person working in that role for the current scope of work, e.g. the team only needs about 20 hours a week of someone providing an architecture (or UX or DBA or whatever) role, but that person needs to fill in 40 hours (or usually more) of work per week.
There aren’t enough people in that role to go around. This is quite common: you have four scrum teams, and two of role X (BA, Architect, whatever). The solution seems simple: you split them 50 / 50, each team gets one half of that person.
Why splitting people across teams is a bad idea
There are a few reasons why people split across teams should be avoided if possible.
Scrum events take up a higher proportion of a person’s time.
Splitting people across teams in Scrum can be a bad idea
I think the Scrum events (please don’t call them Scrum ceremonies) are all important and should be followed. Unless you have specific reasons not to do so. They do take up a decent proportion of your team a week, but their purpose is to reduce the amount of time in meetings, by shortening communication loops. If you put a person on a second team, they need to attend all of that Scrum’s events too.
That means the proportion of time remaining in the sprint for their primary activities decreases. You can imagine what would happen if you tried to put a person in a third or fourth scrum team.
If someone doesn’t attend the events, they will miss out on vital communication loops (from standups) and feedback/inspections (sprint reviews and retrospectives). Not to mention planning and estimation (sprint planning).
Context switching
If someone is working in multiple teams, their attention will be split. People are not as efficient at multi-tasking as many think. Context switching has a cost. It certainly reduces productivity and effectiveness.
A nice quote I heard a while ago was “you can’t split someone 50 / 50 – you can split them 40 / 40. And you can’t split someone 33 / 33 / 33 – you can split them 25 / 25 / 25.”
I think you get the idea. Each time you split someone across teams, they lose some of their overall effectiveness.
Tug of war over priorities
If someone is split across teams and is providing important services to both of them, there will almost certainly be conflict over where their priorities are. That conflict takes up time and energy and could lead to frustrations and resentment. If the product owners of the respective teams have different goals and represent different stakeholders, that conflict will be intensified.
Make sure to apply good Systems Thinking principles when navigating these priority decisions.
Alternatives to splitting people
Split hats, not people
If for example, you need 50% of an architect, get them to join the team full time, and split the “hats” they wear. See if they can be developer / programmer the other 50% of the time.
That might enable you to reduce your developer count in the Scrum, especially if one of those developers is already split 50% across another team (now they can go back to that team 100%).
Split time, not people
Instead of having people running between tasks multiple times in a day, get them to pick certain days of the week that they are 100% on a team and 100% on the other team.
This can potentially cause problems when those days collide with your sprint cadence events (sprint planning, sprint review). But it definitely reduces the impact of context switching. Since you can occupy your mind with one team for a whole work day.
Put your foot down
If all else fails, another option is to just put your foot down and insist that you (or the other person) will not be split and that’s that.
Whether that succeeds will depend on priorities, politics, organizational dynamics and so on.
When it is ok to split people
Scrum masters are sometimes split across teams, especially once a team starts “humming” and becomes more self-empowered and less reliant on the scrum master to help coordinate ceremonies, remove blockers, etc. Scrum masters usually then starts “rolling off” that team and moving onto another team (maybe a newly-formed team).
And that team will quickly become their sole focus, until that team starts humming, and so on.
It is also common to split someone across a team if they have a very specialised role that is only needed from time to time, e.g. a compliance review, enterprise architecture, legal advice, etc. If possible, never split a product owner across teams. Not only is it a difficult role, giving them multiple teams could lead to playing favourites, which will end badly.
Question: have you ever been split across teams? How did it go or how did you manage it?
Frequently asked questions
Which would be a reason to split a Scrum team?
You might want to split a team (not a person!) if the team is getting too big. How big is too big? It’s hard to say. The Scrum Guide doesn’t give a specific rule on this, though recommends teams of 9 or fewer people. A lot of this depends on the context and dynamic of the particular Scrum team. And how experienced the Scrum Master is.
How should a group of 100 people be divided into Scrum teams?
This is a common question in Scrum Master exams. The Scrum Guide itself does not tell you that you (as a Scrum Master) must split a team into 9 or fewer people (or some other number). If you don’t believe me, go check! It simply says that smaller teams are usually better.
As always, good principles of self-organization apply. Teams should be able to figure a lot of this out for themselves. And to find their own best size and way of working.
The job of a Scrum Master is to help facilitate those conversations, not order people around based on some rule.
This video provides an insight into the question of when you might want to split a whole Scrum team (maybe if it is getting too big).
