How big is a team?

When I first started out with scrum in the mid noughties, the Scrum guide’s recommended team size was five to nine people. Since then, this has been changed into three to nine. Now, there is a huge difference between a team of three and a team of nine. So when should you be three and when should you be nine? Maybe it’s better to play safe and always stick to eight?!

Well, that depends!

The more people on the team, the harder it gets to maintain a single focus. A big team may easily become fragmented; suddenly you spend half of the fifteen minutes of daily scrum zoning out from the meeting, since you’re totally disconnected from what five people in the team are doing. Because you’re in a sub team that is doing something completely different!

Setting a crisp sprint goal for a team of nine is very hard. Usually, you end up with three goals at every sprint planning, which means that the team won’t have a clear guiding north star for the next sprint. 

So obviously, big is not always better.

I firmly believe that team size should reflect the number of people that need to work together in order to focus on one major initiative at a time. If your organization deals with a lot of complex and big initiatives, a bigger team size probably does makes sense. This may also be true if your deliverables are huge legacy applications. However, if the majority of your initiatives are quite small, it makes sense to have smaller teams. Especially so if you have begun transitioning to a micro-service architecture.

But if some initiatives are tiny and others huge beyond comprehension? Does this mean that team size will have to vary over time? And wouldn't that mean that we will be stuck in some sort of perpetual "Tuckman loop" jumping between group development stages every time someone is added to or removed from the team.  (N B: By ”Tuckman loop” I mean constantly transitioning between the Tuckman stages of group development.)

My bold proposal is to have your cake and eat it too! Build teams big enough to solve your smaller initiatives. Make sure that the team members work well together and complement each other professionally. Let's assume you do this in your organization and that you then end up with six four-people teams. That covers small initiatives. For big initiatives, build together eight-people teams from the four-people ”atom” teams. You will end up with teams where you know that the majority of team members work well together. This is a big difference from the old-fashioned way of forming project teams from a pool of people (or even worse: resources), where you will never know what to expect!

I am not saying this is a silver bullet, but the joint-team setup has been successfully used for one of my teams over the past two sprints. "My" three-person team is teaming up with a team of roughly equal size in another location for a limited time. With great result! I have also seen other successful examples of the joint-team setup, so it's not a one-hit wonder. 

When putting together two teams in this fashion, my observation has been that they function much like two sub teams do in a larger team. The two micro teams do the sprint planning and sprint review together. Daily scrum and retrospectives can be done separately or jointly, depending on what is best - in the initiative I mentioned above, we have kept having our separate standups and added a full-team standup on top of that, two times a week.

We call this setup Micro teams. Most people who have worked in this kind of micro team love it and don't want to go back ever again to big teams. They love the short, relevant standups. They love the feeling of all team members working on the same thing. And they love the focus.

This is the kind of team that can deliver fantastic value!