By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL
How many cooks do you need in a kitchen? The answer is you can have as many as you like as long as one is the boss. If you don’t have a boss, there’s chaos.
In a kitchen, there is one that is the boss, the Executive Chef (often called “Chef”), and he or she calls the shots. Everyone else (such as the Sous Chefs, Pastry Chef, Line Cooks and all the other kitchen staff) knows exactly how the system works and who’s in charge. In fact, this hierarchy works very well. Just look at any major restaurant or hotel kitchen and you’ll see exactly what I mean. (I’ve worked in restaurants large and small, independent, and as part of a large resort hotel, and I can tell you the Chef is indeed the boss!) Do you think for a second that Gordon Ramsay, Bobby Flay or Mario Batali is not the boss in their kitchens? Think again.
But in Scrum, too many “cooks,” or Scrum team members, really do spoil the “broth” (read: project). Why? Because in Scrum there is no “boss.”
The Scrum team is supposed to be a self-organizing body who figures things out on their own. There’s no Project Manager barking out orders, and the Scrum Master’s role is limited to ensuring the Scrum process is being followed and no one bothers the team.
According to The 2015 State of Scrum Report published by the Scrum Alliance, Scrum teams averaged seven members. The recommended size range is seven, plus or minus 2. Respondents in IT/software development reported an average team size of 6.6 members.
Team size evidently does have an impact of Scrum success. For example:
When there are 4-9 members on a team, Scrum is successful 77% of the time.
When there are 10 or more, Scrum success drops to 65%.
When there are 3 or fewer on a Scrum team, the success rate is only 50%.
So, not only does having more than the recommended number of members negatively impact success, so does having fewer than what’s recommended.
To be sure it’s difficult to self-organize when there are more than 10 team members. First, if everyone is ostensibly equal on a self-organizing team then everyone will have their say, resulting in a large number of opinions that have to be discussed and debated (sometimes endlessly). While the ultimate decision may be sound, oftentimes these kinds of discussions end in compromises. And while a compromise decision may soothe the egos of those involved, it may not be the best one for the project.
I also think that too many team members invoke an Animal Farm mentality, which you will recall if you read Orwell’s classic, can best be expressed and rephrased as:
“All Scrum team members are equal, but some are more equal than others.”
When the “more equal” members assert their influence, the others either fall in line, rebel, or become alienated. Hardly the end result anyone wants from a self-organizing team.
With three or fewer team members, I just don’t think there’s enough diversity of experience and ideas to reach the best decision. Three’s a crowd, as the old saying goes, and perhaps some issues arise when two members feel strongly about one course of action, and the holdout has to simply agree. If that happens enough, the third wheel, as it were, stops rendering his or her opinion.
So, we’re left with seven (plus or minus two) as the optimum team size in Scrum. But wait a minute, seven has always been touted as the optimum number of team members in project management, at least for the core team. So, what’s the big deal about Scrum and the number seven? Not much really, and that’s the point.
We can apply many of the best practices we’ve used all these years on traditional projects on our Scrum projects and, in fact, we should. After all, our only goal is to get the project done successfully. However way gets us there is the route we should take.
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.