Right-Sizing Scrum Teams
The section of the Scrum Guide on Scrum Teams is barely 250 words. Still, there are two specific constraints that enable teams to deliver value. What might these constraints be? Let’s check them out.
When one reads the five short paragraphs on the Scrum Team from the Guide, it all looks very straightforward and simple. There is one sentence, though, with an inherent conflict in it:
The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint.
The Scrum Team — small and large: how is that supposed to work? Let’s unpack how being small and large at the same time serves as an enabling constraint that will make it possible for a Scrum Team to fulfill two of its most important attributes: self-management and cross-functionality.
Small and Self-managed
A Scrum Team is small so that it can think on its feet: smallness means the team is quick to align, pivot, and change tack. If, however, a team is too small, it will not be able to cope with the burden of creating a potentially shippable release increment by the end of the Sprint due to skills deficiency within the team.
If a team is small enough, information flow will be smoother between people, and it is easier for trust to form — leading to another attribute of the Scrum Team: cohesion. Cohesion bonds a group of individuals into one unit as team members explore the Values as they work with Scrum: members can commit to each other which brings focus and openness. It leads to respecting one another for the human beings that members are as well as having the courage to tackle difficult problems.
Living the values does not only bring empiricism to life and leads to trust: it results in better communication which paves the way for an important attribute of Scrum Teams: self-management.
Large and Cross-functional
Still, Scrum Teams need to be large enough to deliver a significant amount of work and produce a releasable increment every Sprint that meets both the Sprint Goal and the Definition of Done. This commitment is super-important in Scrum as it serves as the quality standard for the Increment required by the organization/team. At the same time, the team should not be too large, otherwise, communication and coordination (i.e. the enablers of self-management) will suffer.
Delivering a Done Increment is no small feat. In a software context, team members, at minimum, need to be able to articulate and clarify customer needs, break down a problem, brainstorm and design a solution, craft code through the entire stack, integrate and test that code, and deploy it to production. The only way this can be accomplished within one Sprint is if the team has all the skills needed to go from idea to production, i.e. it is cross-functional. Such a team, however, would become overly large if each member were to have one skill and one skill only. A large team could be cross-functional, but relying on one individual for a specific skill would introduce potential bottlenecks in addition to the issues with self-management detailed above.
For a team to be small and large, that is, for a team to be self-managed and cross-functional, members need to start acquiring new skills either from one another or through learning and training, resulting in them becoming cross-skilled professionals. This is the only way a team can remain small in size and deliver a large chunk of value at the same time.
Conclusion
Size-related constraints in Scrum shall serve as a catalyst for a self-managed and cross-functional Scrum Team to be formed. It may not be a coincidence that these are the exact two qualities that Scrum Masters are supposed to coach their teams on, and having the right-sized team will set up Scrum Masters for success, provided that there is empowerment from the organization and an appropriate team structure is in place.
