Products reflect the structure of the teams that build them, and so a critical decision on any development project is how to organize individuals into teams. In the first installment of a new series on team structure, Agile thought leader Mike Cohn makes the case for keeping teams small, detailing several advantages over larger ones.
Editor's Note: This series is excerpted from Chapter 10 of Succeeding With Agile, which examines critical factors in determining how to structure and manage Scrum teams. Here, in the first installment, the author makes the case for keeping teams small.
I was working on a project for a bioinformatics company when the CEO asked me to provide her with an estimate of how long the project would take. The application was large, the domain complicated, and the team mostly new. Because the domain was so complicated, our team was made up of some very smart Ph.D. scientists, who knew only a little about programming, and some very smart programmers, most of whom had taken no more than a class or two in biology or genetics. No one on the team was great at both the science and the development.
After a bit of research and work with the team I returned to the CEO with an estimate of something like 100 person-years. In other words, if we used all 40 people on the team, we could finish the project in