Team size in Scrum, actually

Self-organization is an essential management principle of Scrum. Yet, its importance and potential are only seeping through slowly. Despite the wide adoption of Scrum.

The most basic form of self-organization in Scrum holds that Development Teams organize and manage their own work within a Sprint, autonomously, against a forecast and a Sprint Goal. Where acceptance of this practice grows, few organisations take it a step further. Few teams are supported to figure out their own team size in order to best collaborate towards the creation of a releasable Increment of product in a Sprint. Understanding that the foundations for great work are commitment and motivation, Development Teams should be able to also create and re-create their structure and composition across time.

Collaboration is key. From collaboration performance emerges. Teams have the highest cohesion, the deepest trust and the most effective interconnections when the size of the team is around seven. Scrum used to have the rule known as 7 +/- 2, meaning a Development Team was expected to have at least 5 people, and 9 at most. The Scrum Guide has evolved this guidance to 3-9 people. This is confusing when looking for academic exactness, less confusing if this is seen as guidance against the goal of being “small enough to remain nimble and large enough to complete significant work within a Sprint“ (quote from the Scrum Guide).

Although the Scrum Guide sets an expectation for the size of a Development Team, there’s no formal process needed to really enforce this if self-organization is enacted. Through self-organization a team will adjust its size autonomously for optimal performance. Rather than instructing a team on their mandatory size, help a team discover what works best for them, including what team size maximizes the communication bandwidth. No external body can do this better. No external body can assess the combined effects of team dynamics, being co-located or not, availability of people and resources (tools, infrastructure), and all other parameters better than the people actually doing the work.

Try something you believe might work for you. Inspect it, adapt to your findings. Repeat. When heavily constrained in doing this, sticking to the guidance of having 3-9 people in a Development Team is a good idea.

In Scrum, actually… team size is a team decision.

Impediments (and where to find them)

Probably the most known purpose (task) of a Scrum Master is to remove impediments. If that is reassuring: it’s even described in the Scrum Guide. A Scrum Master is indeed ‘officially’ expected to remove impediments to development and to the Development Team’s progress.

Unfortunately, this is sometimes interpreted as the Scrum Master having to be an ‘impediment hunter‘. That suggests that a Scrum Master should proactively search for impediments in order to track them down and kill them. There is a danger in this wording, besides the very negative feel to it. I particularly wonder how this aligns with the self-organization of teams and transparency? Self-organization is essential in Scrum and it’s to be promoted, served, coached, taught and mentored by that same Scrum Master. Transparency is required to know about reality, inspect it, learn from it and make proper adaptations.

An impediment is an “obstruction; hindrance; obstacle”. And Scrum is a framework that helps teams in finding better ways to create working software in 30 days, or less, and handle the complexity attached to that. An impediment in Scrum is therefore anything that blocks the (development) team in its creation of a valuable piece of software in a Sprint, or restricts the team in achieving its intrinsic progress.

Where to find an impediment?

We can expect a team to raise an impediment, any annoying problem that is truly blocking them. Actively looking for (‘hunting’) and removing impediments is solving problems that are not a problem yet. It assumes that a Scrum Master, as 1 single person, knows more -or pretends to know more- than the united brains of a complete team of up to 10 people; a team that daily makes hard choices by disciplined collaboration.

Solving a problem before it’s a problem points at a lack of belief in the self-organizing capability of a team. Solving a problem before it’s a problem prevents learning and improving because it obfuscates transparency to the team. Solving a problem before it’s a problem is mostly a waste of time and energy because the team will probably handle it by itself anyhow, without the Scrum Master, preventing it from turning into something that truly blocks them. They probably even solve more problems than the Scrum Master knows or can imagine.

It’s simple, an impediment is not an impediment if it hasn’t been raised by the team. Impediments cannot be anticipated. And if there undeniably is an impediment (not an anticipated one and not an issue that the team is already handling) and it is not being raised, the question of the safety of the environment arises. What is preventing the team from raising the impediment?

Not raising an impediment does block the team. What’s then the real problem for the Scrum Master to solve?

What does an impediment look like?

Issues only become impediments if they cannot be tackled within the self-organizing ecosystem. The concept of ‘impediments’ is not a replacement of the traditional escalation procedures. Traditionally people are told to escalate whatever bothers them to a person external to their work to solve it for them. Easy and convenient. But is it also helping?

Scrum delivers great results because it thrives on self-organization, accountability and skills; it appeals to those elements. Scrum restores the respect for people and the understanding of software development as complex and creative work. By definition, in Scrum an issue only becomes an impediment if it can’t be unblocked through the authorizations of the (development) team.

Let’s illustrate this with the example of a team conflict, a conflict between team members.

A team might have problems in resolving a conflict and call the conflict an impediment, expecting the Scrum Master to remove it for them. They expect the Scrum Master to solve the conflict. However, working as a team inevitably includes getting to know each other, finding ways of building software together, exploring different ways to collaborate, outgrowing the desire for personal heroism, and improving through constructive disagreement. Conflicts are a part of working with people, part of becoming a self-organizing team, part of aiming at high performance.

Once again we should raise the question what the real problem for the Scrum Master is to solve? Is it the Scrum Master’s role to solve the conflict? Or would that be an undesired intervention in the self-organizing ecosystem, undermining future honesty, learning and self-improvement? How can the Scrum Master facilitate self-organization? Is it by offering teams an excuse, an external decision to hide behind? Consider how to help a team work out their problems themselves and offer any tools, trainings and insights on how to do this.

Not dealing with an issue does block the team. What’s then the real problem for the Scrum Master to solve?