SCRUM: Keep Team Size Under 7!

Today, I wrote up an experience report on using SCRUM in large development teams for a new book that Craig Larman is writing. I described how a few teams in a 500 person development group generated production code at five times the industry average, while most of the teams who executed SCRUM well, only doubled productivity over industry average. One of the problems in the large organization is that it was culturally prone to a team size of about 15 people and there was a lot of internal resistance to reducing team size. I now think that this may be the primary reason only a few teams moved into hyperproductive mode. The hyperproductive teams would always split into subgroups of 7 or less, while the poorer performing teams insisted on working as a group of 15.

Jones, Capers. Applied Software Measurement, Second Edition. McGraw Hill, 1996.

There is plenty of data to show that team sizes over 7 result in significantly lower productivity. Any team over 7 in size should be split up into multiple SCRUMs.

Rubin, Howard (Ed.) A Metrics View of Software Engineering Performance Across Industries. IT Metrics Strategies V:9:3, September 1999.

Average cost per function point across over 1000 projects in Rubin's Worldwide Benchmark database is $2970. For teams of size 7, the average cost was $566 per function point. Most companies productivity is (by definition) the industry average in function point analyses done by Software Productivity Research. We may spend about 6 times the necessary cost for each project we do on the average.