Seven to nine, as many as it takes to eat two pizzas, there are many analogies as to how big your Scrum team should be, and most people target this and run with it. But what is the consequence of teams that are larger, are there any benefits?
I was in a situation with what looked like a group of normal sized teams until after a closer look it was apparent that the teams were not cross-functional and that half the skills sets had their own separate independent teams, so we had siloed teams by function – just like a waterfall delivery. As a first step towards an agile transition, people from each “skill” team were added to the original, developer-centric, team. That created what looks like a cross functional team, although inside each we still had a set of defined responsibilities; but that is an issue for another day. What it did create was the rather unusual situation of Scrum teams with headcount in the 18-22 range, something I had never come across before.
Now according to research, pulled on by Mike Cohn in “Succeeding with Agile”, teams of 4-5 deliver the same output as teams of 15-20 in two thirds of the time and obviously at a third of the cost, but this was comparing different teams, with all the other variables between them unknown.
First a quick summary of the issues with large teams:
- Cost of relationships – just too many people to try to understand, and without good relationships we introduce process, and process is waste
- Time for collective understanding, to get everyone to the same level of understanding on a time is exponentially time-consuming because statistically there is more likely to be an individual with a lower level of understanding of the situation the greater the group size
- Overheads on process ceremonies – just takes longer to run a standup
- Social Loafing, the subconscious behaviour to lower individual effort when in a group, proportional to the group size
It wouldn’t be fair to say that there aren’t well documented advantages to larger teams, the most obvious is that larger teams have fewer team to team contacts that the same number of people would have in smaller teams, so there are fewer dependencies to manage.
With these monster teams, the bureaucratic overheads were soon too much to bear, we knew they would have to split down and therefore gave us the wonderful opportunity to directly compare effectiveness by team size. I had a cursory look on blogs, articles etc for examples of this to give me some guidelines or predicted outcomes, but could find nothing, I suspect because it is so unusual to form teams of this size.
So I worked with a team to discuss the issues surrounding team size. I then asked them to each consider their current team productivity as 20 units. Not velocity, more a personal nebulous concept covering all professional activities – I am sure each person had a different understanding but that is no matter as we were only going to consider relative references.
I requested the team then self organise into 5 units – this was very hard because they are role based individuals with fewer than 5 for some roles, leaving some teams with no test capability for example. Each team was asked what their average productivity was now, and predictability it was lower, Critically, summing up the productivity across all the teams came out as less than 20, suggesting that they would be better all together than as five teams.
The exercise was repeated for 2 then 4 and then 3 teams each time understanding what was good and what was less than ideal with the structure.
Finally I asked everyone to stand along a line representing 1 team to 5 teams – like a linear constellation. Majority were for 3 a few 2s and 4s. We had a small debate between the 2s and the 4s and then asked them if they would each consider a 3 sprint trial to 3 teams, after which, if not happy then we’d repeat this exercise but of course with a lot more knowledge.
The “experiment” would be measured through a collectively agreed a set of personal, abstract values such as collaboration, communication and happiness and set them all to 10 at the start; then each retrospective people would compare now to then to give a sense as to whether things were better or not.
So what happened…..
Well those values were a little scatter gun after the first sprint, some up, some down and some teams much more positive than others. From Sprint 2 onwards you could see a general rise, with a poor sprint temporarily bursting the bubble. We are now three months on. There is no question of reverting back to a single team, the values are no longer recorded but would all be approximately double the starting point. I think a key contributor to the improvement was the fact the teams self organised – it was their decision to be in three teams and their decision as to who would be in each of them, people fight harder to make something work if they come up with the idea – gives a sense of ownership.
Regarding velocity – which we all know is a poor indicator of productivity – the original single team had a velocity of 20, each of the three new teams now has a velocity of 20 which supports what Mike Cohn’s text had implied that a small team could deliver as much output as a team three times the size.
Contact me if you want further details on how the split was facilitated or the metrics used to track benefits.