I blogged in April last year about the importance of teams being a ‘cohesive unit’ rather than just a collection of individuals. This post expands on that concept.

Imagine an athletics club with 20-30 members. Those members agree to a football (soccer) match with another athletics club, so they begin working on their football skills, as well as all of the supporting attributes; not everybody will be on the pitch at the same time, so the rest agree to help with things like strategy and tactics, or to be ready to be substituted in when others get tired or injured.

The athletics club in this scenario is a single team, working towards a single goal (‘to beat the other team at football’).

A few weeks later, the club starts playing basketball as well, and they arrange a basketball match with a rival club on the same day as another football match with a different rival club. They have enough people to participate in both, though they will have fewer supporting people and substitutes available.

How should the team respond to having two separate initiatives?

It seems logical that the teams for each sport are decided early on, so that they can each work on practicing their chosen sport, and start working on things like set-pieces and deciding their tactics and strategy for their respective games.

The teams will likely continue to work together at a higher level — they may still be able to help each other in certain areas, or there may be training facilities (like gym halls) that they need to share and co-ordinate their use of.

If this same problem were in software, I know from experience that most organisations would tackle it in a very different way.

If this were in software, the team would continue to operate as one, even when it is anticipated that they will work on separate initiatives for quite some time. They will plan together in a single Sprint Planning session, and synchronise process and adapt plans at the same Daily Scrums.

In so many cases, this simply doesn’t make sense. To have a single team try to achieve two completely separate goals is a flawed approach, because the concept of this being a ‘team’ just doesn’t apply.

A single team can work on different features, but it only makes sense if there is a single goal. For example, a team could work on ‘registration’ and ‘login’ with a common goal of ‘authenticating users’. Even ‘registration’, ‘login’ and a ’shopping cart’ could contribute towards a single goal of ‘allowing signed-in users to purchase products’.

But, when the initiatives cannot be grouped together to solve a common purpose, or ‘user journey’, then it seems unlikely that the work to do them is going to be connected enough to warrant a single team working on it.

When a team is working on multiple goals, they need to ask themselves very honestly if they are still truly a single team, or whether they could be more productive if they were to wholeheartedly embrace the separate initiatives.

There are of course challenges associated with splitting teams, many of which are worthy of blog posts in their own right. There is no guarantee that even a healthy team will survive significant changes to its structure, and even at best a short-term dip in performance should be anticipated.

But greater issues are likely to be faced by smaller teams — it would probably be foolish to split a team of five people leaving “teams” of just two and three.

Final thought: Splitting teams should not be seen as an alternative to effective planning practices or effective Sprint Goals.