Let’s play a little with the rule of thumb that every team member you need to communicate with, reduces your Ideal time by some percentage.
Let’s assume that all developers in team are equally productive, and everyone can make the same Ideal time per Project day. And first, we start with a team, where every developer has to communicate with every other developer in team:
Let’s calculate the productivity of such teams for 5%, 10% and 15% of communication overhead:
On vertical axis, team productivity as factor to a single developer. On horizontal axis, the number of team members. The interesting result of the calculation is that, according to the model, even with unrealistically low communication overhead (5% with 4 Ideal hours per day means just 12 minutes of communication per day), the largest feasible team is around 10 members, and it is only 5.5 times more effective than a single developer.
Now, let’s now restructure the team. We split the software to be developed in several parts, and define explicit, well-documented, carefully designed and slowly changing APIs (or better yet: data exchange formats) between the parts. A team of 10 can then consist of three independent groups, and a team lead. Each group has a developer lead, communicating with the team lead. Inside the group, every member (including the developer lead) communicates with every other member:
In such a team, there are 6 developers who only have to communicate with two other team members, and 4 developers, who communicate with three other team members. This makes the team unbelievably more effective: while the fully connected team with 10 members is (at 10% communication overhead) only as productive as a single developer, the hierarchically structured team is 7.6 times more productive than a single developer. At least, according to this simple model.
Can introducing good APIs, and structuring the team around them really improve team productivity by order of magnitude?