Using Agile methods with large teams is a reality - the old Agile = Small Team equation is no longer valid. Nonetheless, team size is still an issue. How important is team size and what, if anything, should we do about it?
An interesting discussion started on the ScrumDevelopmentList when one member suggested that team size should be anywhere between half a dozen to two dozen:
split the team - depending on the source, the recommended size seems to vary between half a dozen and two dozen team members.
Huh? In Scrum the recommended team size is 7 plus or minus 2. Isn't this a Scrum forum?
A conversation ensued regarding the definition of Scrum and team size. When the dust started to settle, Roy Morien commented and asked:
No direct answers have been given yet on ScrumDevelopmentList, but Tom Scott blogged about a presentation given by Dave Thomas at Spa 2007 that touches on this subject:Scrum overcomes these problems to a considerable extent with it's emphasis, at least philosophically, on regular, but short, meetings, on collaborative actions, on 'information radiators' etc. But Scrum itself cannot fully overcome the problem of big teams. This matter goes back decades ... James Martin over 10 years ago talked about "SWAT" Teams (Specialists with Advanced Tools, if I recall correctly), which were of limited size ... 5 or 7 or so, but the emphasis on small, for effectiveness.
What seems to me to be a more rewarding and informative discussion is about the ability of agile methods, and agile project management methods, to 'scale up' to large teams, and large projects. Or, probably more to the point, the best team sizes, and the possibility of multiple teams, and the problems of multiple teams, if and when using agile methods.
So ... straight question(s) ... what is the optimal team size (regardless of any prescription by Scrum officianados)? Is Scrum able to scale up to be used by larger teams? How can Scrum principles and practices be applied in a multiple team environment? AND is there any research, experience, or anecdotal evidence and publications to support the answers?
The answer? [to the question How can small teams can deliver big projects?] Divide the big project into small independent projects. Nothing too shocking about that. But there is still a question about how to organise the work and structure the project. Earlier in the year I attended Spa 2007 where Dave Thomas outlined one approach.
The objective is to let projects have freedom to create the solutions to specific problems but to coordinate activity between projects. The approach is to structure the work into four phases:
- Envisioning;
- Definition;
- Development and;
- Release.
And, Pascal Pratmarty on his blog wrote about the Inefficiencies and large teams:
When is it profitable for a team to grow? Do we really need big teams to handle big projects?
I deplore the fact that so many people measure the importance of a software project by the sole size of the team working on it.
Many members certainly imply more brainpower potential, but also a greater difficulty to realize this potential. Actually, I notice two common pitfalls for crowded teams, namely miscommunication and lack of motivation.
There is consensus that small teams are much more efficient and productive than large teams. But larger teams are still being used to cut more code because small teams lack the capacity to produce as much code - or do they?s
