Scrum Ninjas and the size of Scrum teams

We all know the two pizza rule. There is a good reason behind the recommended scrum team size of 3..9. Too many members and the communication gets chaotic and too few, there aren't enough interactions to make sense.

What happens when reality strikes? R&D projects with a 3 person development team? Or a web project where you want the backend and front-end team to work closely - at least initially for the first few sprints? Scrum ninjas will lash out at you for stepping outside the boundaries. They will declare you as the bad guy and tell everyone around that you're killing Scrum.

Scrum is a very common sense process. It evolved from observing what works and what doesn't, so let's not forget the intent of the Scrum and the Agile Manifesto. If there is a choice, sticking to the two pizza rule is great but if there are just two developers on a project, do we shun Scrum just because the team fails the size test? I would argue that there are enough tools in the Scrum arsenal to make it still very useful. The product backlog - one of the best requirement management tool out there. We can use that. We can work iteratively and delivery potentially shippable product increments. Now, Scrum Ninjas will kill me for saying this, but a daily standup for a two person team may not be useful when they are sitting next to each other and communicating all day. If they are not sitting next to each other, we should fix that. If they aren't talking to each other often enough, we should fix that. But asking them to follow a ritual stand up daily? it depends on the team members and I would empower them to decide.

Now, large teams - this is an absolute killer. Scrum Ninjas will cite 100 reasons to split the team. Yes, that should be the goal but we have to see the intent behind the large team limits. Communication among team members, as we know gets more and more complex with increase the size of the team. The formula is as follows:

The number of communication channels = n(n-1)/2. where n= number of stakeholders

This means, that for a team size of 5, the number of channels is 10, for a team size of 7, it is 21 and for a team size of 10, it is a whopping 45.

If we split a 10 people scrum team into two teams of 5, ideally we are reducing the number of communication channels from 45 down to 21 (10 within each of the two team and 1 between the teams). In practice though, 1 channel between teams may not be sufficient. We need to consider this aspect before taking a decision to split. If there is no significant reduction in the number of communication channels, then adding risk and complexity by splitting the team isn't worth it. The real goal should be to reduce the complexity of communication first and organise the teams into Scrum of Scrum over a period of time and then split the teams. Until that happens, the communication channel formula is a good shield against Scrum Ninja attacks.

As a Scrum Master, it is very important to understand and share the intent behind Scrum guidelines with our team members. As for Scrum Ninjas, common sense is the weapon of choice.