Software is social. The average software project requires at least a few developers. And with that group of developers comes the meetings, lunches, inside jokes, occasional late nights, Internet memes, practical jokes, Friday morning bagels, launch parties, and, of course, actual software. And I haven’t even brought in project managers, quality & requirements people, sales & marketing staff, support specialists, etc.
The social dynamics of software development is far too large a topic for this humble blog post. But one facet of the social aspect of software development is team size – what’s too small, what’s too large, what’s inefficient, what’s cost effective, what works?
When it comes to matters of team size, Agile encourages the practices of Pair Programming and Whole Team. We practice both. Even the smartest, most thorough, most capable developers make mistakes and go down blind alleys that could be prevented with a second pair of eyes (i.e. pair programming). In the difficult task of getting software right, having the customer (or all those involved in creating software) included as an intimate part of the team is invaluable (i.e. Whole Team).
Beyond pairing and bringing customers & non-developers into the development team, other size factors are also at play. In fact, research in the fields of psychology and even primatology has something to say about team size.
Pairing is the hour-by-hour mechanism of software development in our office. But what about really tricky design issues or big decisions that will affect the entire course of a project? Is a pair enough for those decisions? Research demonstrates that groups of three are the most proficient and efficient at problem solving. Anecdotally, I feel that my best problem solving sessions have been in groups of three. So this makes sense to me. Pairing is efficient at increasing overall velocity, preventing basic coding errors, and spreading project knowledge. It’s the really tricky problems where one gets up and away from the computer to think and talk where the rule of three comes into play.
At Atomic Object we use stories, planning poker, unit & system tests, and burndown charts to measure development velocity and predict project completion. Using these tools, it’s very easy to analyze and demonstrate that each project has an upper empirical limit to how many developers can be added with an accompanying increase in velocity. The marginal improvement in velocity for adding each developer is bounded by communication overhead and the number of semi-independent tasks that can be tackled at one time. I don’t think we’ve ever had more than six developers (three pairs) on a single project. Throwing more developers at a problem beyond that particular project’s effective team size limit is wasteful and can, in fact, slow down the project.
Though I’ve never been a part of a truly huge project, I know some have involved tens and hundreds of developers. And certainly, beyond only software development, issues arise with how departments and entire companies organize themselves when large numbers of people are involved. Comparative research in primates has predicted certain facets of human social group size and organization. For instance, though disputed, it may very well be the case that how armies have organized themselves over millenia is a consequence of how many people a single individual can effectively socialize with. Given this, we might be best served in organizing our companies and departments and software development not in ways that look good on org charts or spreadsheets but in ways that allow for and encourage socializing.