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.

Ceremonies take up a higher proportion of a person’s time.

I think the 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 ceremonies 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.

If someone doesn’t attend the ceremonies, 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.

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.

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 adeveloper/programmerr 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).

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.

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?

Leave a Comment: