Estimation & Amdahl’s Law
Understanding the work done by Gene Amdahl in the field of parallel computing
Let us take this opportunity to explore a theory (involving Amdahl’s Law) one needs to be mindful of before even wanting to turn estimates into facts in the future.
Who is Mr Gene Amdahl?
Gene Myron Amdahl was an American computer scientist and primarily known as the brain behind Mainframe computers at IBM. He formulated Amdahl’s law, which states a fundamental limitation of parallel computing.
What is Amdahl’s Law?
Amdahl’s law is a formula that gives the theoretical speedup in latency of a task at a fixed workload that can be expected of a system whose resources are improved.
I can understand your pain and read your facial expressions now after you read that statement.
Never mind, let me put it in simple terms for everyone’s benefit.
When we set multiple Scrum teams (or Developers) to work on a larger task by dividing the effort, they have to integrate their work.
If that integration work is large, the forecast made around those multiple teams doesn’t holds good to a larger extent.
We need to consider this diminished power to predict 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 power lost in predictions you will see might shock you.
The Amdahl’s formula for your reference:
S-latency (s)=(1−p)+sp 1
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.
Estimating Product Backlog Items & Amdahl’s law
Amdahl’s law helps us to understand that it is the proportion of a ‘task’ that can be parallelized that limits total computation speed improvement.
Assume we are building an application to book a movie ticket and features associated with the same are fragmented and pulled by individual Scrum teams. We can observe those individual features working fine as per the plan but those intermediate feature workflows have to be integrated to realize the overall business value in that time. If this integration step can only be done at the end, this might create a challenge to the estimates and associated target dates identified upfront.
Batch size, teams’ capability, problem complexity, etc. are some of the factors impacting estimates we need to remember. When we are estimating work, we shouldn’t assume a higher throughput than Amdahl’s law shows and not be surprised even if it remains less.
For better forecasting into the future, we need to put a few engineering practices in place:
- Integrating work continuously
- Testing continuously and as a whole
- Deploying work continuously
In short, we need to increase the parallelizable proportion to 100% by eliminating all sources of integration or dependencies.
Am not convinced; I still want to add more people to help meet the target END dates
Adding more individuals/teams doesn’t always mean doubling the amount of work and meeting the target dates at ease. If you are not convinced yet, find below how your proximity of meeting the target END dates come up applying Amdahl’s law and statistically inferring a data sample. I took a data sample of increasing the existing teams with 40, 100, and 200 more individuals to get the work done with the same 80% parallelizable proportion.
At the same, taking a fixed program size of 40 members working in parallel (spread across ’n’ Scrum Teams) and increasing the parallelizable proportion, here is how the data looks:
Wrap up!
Quick Win is with increasing parallelizable proportion to 100%. But how?
Minimizing the cross-team dependencies through cross-training, distributing specialized skills wisely across all Scrum teams (making it more generic eventually).
Focus on improving communication patterns in addition to Continuous integration, Continuous Testing, and Continuous deployment as appropriate.
Without paying attention to software craftsmanship, expecting an estimate to hold good and help in timely delivery is nothing less than praying hard for a pig to fly.
*All the calculations are done using tools and resources from www.focusedobjective.com
