How to design a team that would produce software of good quality — team size

As discussed in the parent article, team size should be as small as possible to provide value to the client.

To note:

Studies prove that the smaller the team is, the higher the quality.

There’s another study by QSM which says:

Teams of 3 or fewer people were the most likely to achieve balanced schedule and cost/effort performance.

Teams of 2 or fewer achieved the best cost/effort performance.

Teams of 2 to 4 delivered the best schedule performance.

Teams of more than 4 people resulted in dramatically worse cost/effort and schedule performance.

The stated reasons are as follows:

1. information is lost in every act of communication (hence communication path should be as short as possible)
2. there’s a limit to productivity increase when work is parallelised (due to sync costs)
3. management complexity grows with every new team member

The first reason is well defined in the parent article.

I want to go through the second in more detail here and the third in the following article.

Limit to productivity increase with work parallelisation

The longer the team performs a task, the higher the chance that the task is waste — the world changes quickly, and clients’ needs change even quicker. The Agile movement started to motivate the companies to perform in smaller iterations much faster, checking in with the client to see if the delivered product satisfies their needs (and this is exactly what quality is!).

Naturally, the team is motivated to deliver each iteration as soon as possible — to check if the quality is at the desired level.

So speed is crucial to quality.

And we started this article by saying that the fewer people, the better the quality.

These two principles seem to contradict, don’t they?

Not really.

Amdahl’s law states that there’s a limit to a speed increase when the work is parallelised.

Any parallel execution requires coordination (synchronisation). Synchronisation by default is synchronous. People and tasks aren’t equal, so some people and tasks will have to wait for the sync to happen. When there’s a wait time, delivery time decreases.

Please read this article for more details, but here’s the essential quote:

Assuming 12% of the workload needs to be synchronized to facilitate healthy collaboration within the team, and if we want a reasonable minimum efficiency of 0.3, then the answer is a size of 6-7

The concept we get from Amdahl’s law is simple: reduce the amount of parallel work to the bare minimum (not more than 6-7 items in parallel) and make sure this work is performed as fast as possible.

Interestingly, Kanban method has a concept called WIP limit:

WIP is the number of task items that a team is currently working on. (in parallel — added by me)

WIP limits are considered an important prerequisite for delivering value to customers as fast as possible An empirical study of WIP in kanban teams

Kanban talks a lot about figuring out how much work to parallelise and what effects to expect.

There’s a study proving that the use of Kanban’s concept of limiting WIP does result in improving the team delivery speed.

So if we unite Kanban’s principles and Amdahl’s law, we see that the optimal number of people working in parallel on tasks shouldn’t exceed 6-7.

References:

• The Ringelmann effect: Studies of group size and group performance
• Team Size Can Be the Key to a Successful Project
• Familiar Metric Management: Let Me Count the Ways!
• How much improvement do I get by adding more teams or people?
• An empirical study of WIP in kanban teams