The size of the scrum teams



Much has been read and spoken about the size of the teams in Scrum, Agile, etc. We know perfectly well, by way of introduction and overview, a Scrum team should be multidisciplinary, by definition. That is, all the necessary roles included in the kit, to make a valid Product increase at the end of each Sprint. Until there all right. That is the best team Scrum to be productive and autonomous. That is the starting point for all Scrum team.

Scrum guide says, that the optimal team size is around 7 plus / minus 2 people. In short, the equipment should be between 5 and 9 people. cases teams of 3-4 people can be perfect. Later in the article we see that brings that size. But what is clear is that ever a team has to have more than 9 members. Why?

Already in 1983, Ikujiro Nonaka and Hirotaka Takeuchi such statements formulated after conducting research and new products in technology companies such as Juji-Xerox, Canon, Honda, Epson, Brother, 3M, Hewllet-Packard. In these studies, and later by Jeff Sutherland and Ken Schwaber to create Scrum come to affirm and demonstrate that those teams set up around 7 plus / minus 2 members generate a level of average productivity of a 300-400% more than a team normal 500% if you get to develop a great team or elite team.

A small team, 3-4 people does not make much interference, can be very autonomous with guidelines and a well-defined focus, being physically in the same space, work is consistent, responsible, aligned, without "trodden", well targeted and with fluid communication. Everything is easy with few individuals in the team. The problem appears to increase the number of team members.

Brooks's Law states that "adding personnel to a software project that is delayed delay it even further." It could even estimate what amount or percentage gets delay the project, but it is clear that delays, no more. You have to train that person on the product or technology, and will have to learn a non-technical knowledge, if no longer functional, and tactician on the product or software.

According to major studies by great personalities like Lawrence Putnam, a small team (under 9 persons), it requires 25% less effort than large to make the same product (between 9 and 15 people) one, which affects between 15-20% of productivity per team member, if we calculate a simple average we subtract 150-200% productivity on the computer.

In short, if an optimal equipment we can get to have a 300-400% productivity. And for whatever reason we add more people (surpassing the border of the 9 members) get remainder productivity 150-200%. 300-400% - 150-200% = same maximum productivity with a team of 9 or fewer members. And maximum productivity is said, indicating that a rule will be less productive, your product will be more expensive (more members of more cost equipment) and will be extended over time to be less productive.

Finally, not to elaborate any further and conclude in 1956 George Miller claimed and demonstrated that the maximum number of relationships and items that a person can hold in your short-term memory is 7. Later in 2001, Nelson Cowan, showed that Miller was wrong and had been very ambitious, he showed that it was only 4. with this statement it is clear that between 4 and 7 have good results, whatever is trying to go beyond, we are impacting team productivity, and therefore costs and deadlines.

Thus, it is now very topical a term called "Descale" or what is the same de-escalate. If we apply the same principles, studies, metrics that have been listed in the rest of the article, we obtain a scale of 4-5 teams teams of 7-9 people maximum we would be making a product perhaps 200-300% more Scrum productivity without realizing it. This can give us an average of a line of development for a product of 50 people, not 150 or 200 people. That certainly would have at most the same productivity as well scaled with Scrum teams and maximum 50 members.