Hello again, By reading the title you might have thought I’ll be explaining about some algorithm/tool but for a change let’s talk about project management and how adding a new person(at a specific time) into the project could be dangerous and what to avoid. Let’s get straight into the topic of Brook’s law.
Here is the definition according to Wikipedia.
Brooks’s law is an observation about software project management according to which “adding manpower to a late software project makes it later”.
According to Brooks, there is an incremental person who, when added to a project, makes it more, not less time.
- It takes some time for the people added to a project to become productive - ramp-up time
- Communication overhead increases as the number of people increases.
- Limited divisibility of the task could cause more chaos.brook’s law
You could be one of many who think as this doesn’t make any sense. Does this mean we should never add people to a project? You must be kidding…
Calm down. Let’s not get into any conclusions. Firstly, we will see the applicability of the law and find solutions ;)
Brooks’s law only applies to projects that are already late. The schedule for the project is originally overly optimistic.Quantity, quality, and role of the people added to the project also must be taken into consideration.
Let’s consider a real situation and see how it influences.
Assume we are a team of 6 doing a project for client X. We have a schedule of completing the project in 10 months. But, after 5 months there are few more things added to the backlog on top of agreed requirements. But still, we committed to delivering on time.
So the project manager decided to add 2 more developers and 1 QA person into the team hoping this change could boost productivity and have everything ready by the deadline.
But the team deliverables have come down. The pace is getting slower. Then the project manager decided to do a retrospect to understand the situation.
Project Manager: We have 3 more people into the team, Whey are the deliverables slow.
Team: ????
What do you think is the reason?
Yes. You are right. It’s because of new members(Not literally). It takes time to have the new members understand the project and get into a productive phase.
Yes. You are right. It’s because of new members(Not literally). It takes time to have the new members understand the project and get into a productive phase.
What do you do now? Add a few more people? No. Never think about that. Instead, let’s reconsider the timeline and find what caused the delay in the first place.
So, that’s Brook’s law. Let’s see how we can avoid this problem.
Firstly, be pessimistic about the deadlines. Having a buffer is always good.Have engineering standards in place. Continuous integration, test-driven development, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability.The expertise of individual members would have a major impact on deliverables.
Brook’s law never says you shouldn’t add people. It just says you’ll be delayed. This can be OK if you get high-quality individuals into the team (or) the team is more resilient to change. Time is not the only success criteria. If the people you are adding fills an important role in the team, being later might be worth than never.
Conclusion:
A better understanding of the requirements and being pessimistic about goals, Knowing your team strengths would help to plan and deliver things on time. Frequent retrospectives to understand the velocity of your team is necessary.
Thanks for giving it a read. Goodbye until next time.
code = coffee + developer
References
- Applying brook’s law
- Applying brook’s law