Brook's Law
When Ingo Pieper is allowed to use thermodynamics to predict wars , I think I’m allowed to indulge myself in using kinematics as an analogy for planning in ICT projects.
This was inspired by the use of velocity (points per sprint) in most agile projects. Mind you, the scrum guide is not talking about story points or velocity anywhere.
a body in rest.
At first a team will achieve goals with a certain velocity like $r=v*t$ where
- r stands for the distance to be traveled the desired goal.
- t stands for time passed,
- v stands for the velocity to amount of work the team can do.
accelerate
But most of the time business is not satisfied with a steady pace and like the very hungry caterpillar they want more. Since $v=a*t$ where
- a stands for the acceleration.
we have to accelerate to increase the velocity.
Newtons’s second law says $F=m*a \Rightarrow a=\frac{F}{m}$ where
- F stands for the force, the number of people
- m stands for the mass, the work to be done
The natural reaction is to put in more people (or even worse more hours with the same people) to accelerate.
special relativity
Enters Special relativity. According to the Lorentz transformation $m_{S'} = \gamma m_S$ where
- $\gamma = \frac{1}{\sqrt{1 - \frac{v^2}{c^2}}}$ the Lorentz factor
- c is the speed of light
So with speed increasing to the speed of light $lim_{v \to c} \frac{1}{\sqrt{1 - \frac{v^2}{c^2}}} = \infty$
The mass increases and again more force is needed to get the job done.
In this analogy the limiting factor is the speed of light which is a constant in the normal universe, but in developer space productivity is limited by several distractions:
- amount of time spend in meetings
- easily understand the code
- confidently making changes
- quick onboarding in projects
- the quality of the code
- doing he most important things
These factors don’t only add up but sometimes also multiply (with a factor < 0) In his book The Mythical Man-Month Fred Brooks already formulated this (in 1975) and is now known as Brooks Law.
Main takeaways are focus on quality, often refactoring, fast delivery, effective communication and most of all automate as much as possible (testing, delivery, building, deploying) It will make the current team more effective and will result in a higher velocity
Disclaimer: As with any analogy this only goes as far as your own imagination.