Two-Pizza Teams
The idea of Two-Pizza Teams has been around for a few years, but I just saw it a couple of days ago. I think it is the best term I have seen describing the optimal software development team size. The idea is that your team should contain no more people than can be fed by two pizzas. To give this a figure, a team of 5 – 10 people is perfect.
The idea behind this is that you shave off small problems and give them to small teams to solve. The team is completely autonomy and owns both the problem and the solution. This allows the team to innovate and create the best possible solution. In addition, since the team is so small, communication is fast and everyone stays on the same page throughout the project.
I think there are a few other advantages to having small teams which are:
- There is nowhere for anyone to hide. It is easy to recognize the dead wood and build small, efficient teams of highly skilled people
- There is no space for specialization. Everyone on the team has to become proficient in every area within their discipline and beyond. A specialization represents a possible bottleneck, so everyone has to learn how to do all the different jobs. For example, you wouldn’t want a dedicated DBA so all the devs needs learn how to work with the database. The result is poly-skilled workers who are able to move from team to team and from technology to technology and have richer tool sets with which to solve problems.
The best anecdote I have heard comes from IBM. Apparently, there were two teams at IBM both of which were trying to develop the same software. One was large and the other small. The software was non-trivial, something like an operating system. Software that you would expect a large to team to have to handle. In the end, the large team was over budget, over time and did not meet all the requirements while the small team met everyone of their milestones and their version contained all the features. (I believe this is properly documented in The Mythical Man-Month)
In reading about this idea, I came across several blogs that basically said there are some problems that must be solved by large teams. I think the above example proves this wrong.
One last thought about this is that teams should always have an odd number of people on them. This way, there is always someone to break the tie.
Other links: