Article: How much improvement do I get by adding more teams or people?
You probably suspect that adding a second team doesn't always mean doubling the amount of work delivered. You probably also suspected that doubling the size of a team doesn't double the throughput. You're right.
TLDR; Use this calculator to quickly estimate the speedup by adding parallel people or teams. Unless they can work independently, don't bother - it's just expensive for no benefit.
See my ONLINE calculator
OK, so you asked for the detail, and I love you for that.
The amount of improvement assuming all skills and performance of the additional resources are equal (they won't be) is limited by how much synchronization and integration work is needed between the teams. Gene Myron Amdahl, set about giving us the formula to estimate the total computation speed improvement by adding more processors to mainframes, and his formula is known as Amdahl's Law.
Amdahl's Law helps us understand that it is the proportion of a "task" that can be parallelized that limits total computation speed improvement. For example, if we are sorting numbers, we can sort segments of data using multiple processors, but these intermediate results have to be synchronized into one result list. That synchronization/integration step can only be done on one processor which will limit the total improvement time.
Although I hate referring to people or teams as "processors" the principle of this law holds true for software work as well. When we set multiple teams (or people) to work on a larger task by dividing the effort, they have to integrate their work. If that integration work is large, the improvement of multiple teams will diminish.
We need to consider this diminished improvement when explaining why doubling the number of teams comes nowhere near close to doubling the amount of work we can deliver. Until we minimize, automate, or eliminate the integration steps required to co-ordinate that work, the improvement you will see might shock you.
Why is this the best case?
The original Amdahl's Law estimated improvement where the computation problem is fixed size. Highly unlikely in our case that every team does parallel work of identical size. Also assumed is that every team and person has the same individual performance. Also, highly unlikely in our case that every team has an identical skill in solving similar problems. The key point is: When you are forecasting, don't assume a HIGHER improvement of throughput than Amdahl's Law shows, and don't be shocked if it is in fact less.
What parallel proportion is common in Agile?
It comes down to how work gets integrated into the master code branch, tested as a whole, and deployed. The more automation you have to integrate earlier, the better the parallel proportion. I've not seen it above 80% unless it is a team with no dependencies on integration between them and production. If in doubt, use 75% if you have a single code-branch and fully automated integration and deployment. Go 50% if you have manual steps to integrate and deploy. Just guidelines.
How can we improve the speedup?
Simply put: Increase the parallelizable proportion to 100% by eliminating all sources of integration or dependency. It can be costly to get those last few percentages of parallelizable work, so don't go crazy!
Some ideas:
Single branch development - make people integrate early and often to avoid hard and problematic large integrations
Continuous Integration - integrate and regression test automatically on code check-in. Find those integration issues immediately.
Minimize cross-team dependencies - cross-train and distribute specialist skills that might be needed across multiple teams, not centrally in a single team
The Math: Amdahl's Law
\mathbb S_\text{latency}(s) = \frac 1 {(1 - p) + \frac p s}Slatency(s)=(1−p)+sp1
where
- ''S''latency is the theoretical speedup of the execution of the whole task;
- ''s'' is the speedup of the part of the task that benefits from improved system resources;
- ''p'' is the proportion of execution time that the part benefiting from improved resources originally occupied.
source: Amdahl's LAw - Wikipedia
|
Policy "Register once, attend many times"
