“Empiricism” and “Self-organization” are essential management principles embedded in Scrum. They form Scrum’s DNA, the core beliefs for a Scrum eco-system to take shape.
Empiricism is the methodical approach of inspection and adaptation. The technical process feel to this aspect of Scrum partially explains why it typically meets less resistance. Additionally, there are the immediate and tangible benefits resulting from the closed-loop feedback control offered by Scrum. It helps at organizations facing the urgent need to quickly increase, at least minimally, their ability to adapt. The increasing business awareness that this ability (to act with agility) is needed more than ever is helpful in accepting the shift from predictive to empirical management.
Unfortunately, the importance and the immense potential benefits of self-organization are seeping through much slower. Despite the wide adoption of Scrum. Self-organization obviously resides more in the people part of Scrum. The foundational view that people are not, and should not be treated as, ‘resources’ (robots, cogs or replaceable pieces of machinery) goes against one of the hardest relics of the industrial paradigm. It explains why self-organization meets such strong organizational counter-forces, and is often even actively and openly fought and rejected. The longing for the old days of command-and-control (and the status derived from being ‘in control’). Add to that that the impact of self-organization is less obvious, with less immediate or visible impact.
Scrum practitioners across the globe need to realize that the ambition to re-humanize the workplace continues to require a lot of attention and energy.
Look around in your organization. Look at the effectiveness of the traditional manager-led ways of working in today’s creative and cognitive work environments. Consider the arrogance of a single person believing to know better how to organize than the collective of highly skilled people accountable for that work. Do your work plans and instructions still come from one person only (or some other external instance)? How can one person claim to know more than the collective intelligence of a full team’s collected brains when having to address today’s highly complex challenges, often related to modern, fast-evolving technologies?
Regardless whether that one person is a manager, a department head, a team boss, the enterprise architect, the resource manager, the Scrum Master, the most senior developer, the CEO, it doesn’t work anymore (if ever it did). There is no doubt that a manager-centric approach limits the progress and the work outcomes of a full team to the knowledge and insights of one mind. Moreover, it is likely to kill and impede, rather than invoke, creativity and commitment. It is a dead end. The road to high-performing teams begins behind the door called “self-organization”. Only opening the door will start unleashing the collective intelligence of smart people that were hired to do smart work.
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. No forces external to the Scrum Team intervene in their work, progress, tasks and problem-solving. The Scrum Team, and within it the Development Team, is self-managing. If external forces can demonstrate they truly have a stake in the product and its development, they will be invited by the Product Owner to the Sprint Review where they can actively collaborate with the team. If such forces have burning questions that cannot wait until the next Sprint Review (which in most cases of Scrum nowadays is less than 2 weeks away), they take it up with the Scrum Master or the Product Owner (depending on the subject).
Although this basic form of self-organization is embedded in Scrum, experience shows how incredibly challenging it is for organizations to accept it, let alone to embrace and foster it.
And even then, few organisations take it a step further. Few teams are allowed, let alone encouraged, to be self-designing, e.g. the team deciding over team size. Few teams are supported, let alone encouraged, to figure out and establish their own team size against the goal to best collaborate towards the creation of a releasable Increment of product, no later than by the end of a Sprint. It seems that most organizations have quite some individuals that think they know best how many people it takes to optimally perform work, and know it better than the collective of highly skilled people accountable for that work. Like managers, department heads, team bosses, enterprise architects, resource managers, Scrum Masters, the most senior developers, the CEO.
Understanding that the foundations for great outcomes and high performance are commitment and motivation, Development Teams should be able to create and re-create their structure and composition across time. They feel and live on a daily base how collaboration is key. They have skin in the game. Research shows that teams have the highest cohesion, the deepest trust and the most effective interconnections when their size is around five to seven. Scrum used to have the rule known as 7 +/- 2 (‘seven plus-minus two’), meaning a Development Team was expected to have at least 5 people, and 9 at most. In line with research and reality, the Scrum Guide has evolved this guidance to 3–9 people. Specific numbers can be confusing when looking for academic exactness, less confusing if this is seen as guidance (quote from the Scrum Guide):
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.
Although the Scrum Guide gives guidance, no formal process is needed to enforce team size if self-organization is enacted. Through self-organization a team can adjust its size autonomously to optimize collaboration, performance and results. Rather than instructing a team on their mandatory size, help a team discover what works best for them, including what team size optimizes the communication bandwidth. No external instance can do this better. No external instance can assess the combined effects of team dynamics, being co-located or not, availability of people, skills and resources (tools, equipment, facilities, infrastructure), and all other parameters better than the people actually doing the work.
Try a size you believe might work for you. Inspect it, adapt to your findings (remember that inspection without adaptation is pointless in Scrum). Repeat. When heavily constrained in doing so, sticking to the guidance of having 3–9 people in a Development Team is probably not a bad idea.
Team size in Scrum, actually… best is a team decision.