You no doubt have heard of Brooks’ Law: Adding people to a late project will make it later, popularized in his 1975 book The Mythical Man-Month. But more than 35 years later, the practice still happens, with predictable results.
But where do these new resources come from? Hiring takes too long, so they’re likely to come from other teams within the same company or even department. Software engineers are software engineers–the fungibility fallacy. So these teams now suddenly find themselves short-handed, and looking to shift the lost resource’s responsibilities onto the remaining team members, who now have to get up to speed on their new responsibilities in the same exact way that the transferred member has to get up to speed. This perturbation reverberates throughout the team as everyone is disrupted, and that perturbation reverberates long after the lost team member returns.
In many cases, it’s better to let the lost team member’s work go unfulfilled in order to reduce the overall disruption. After all, they’re only supposed to be on temporary assignment, and, unless someone else on the team is already up to speed on what the lost member was doing, they’re not going to be productive for a few weeks anyway. Now multiply that productivity loss by everyone who is re-tasked, and you can see that re-tasking is expensive. I’m all for having multiple people having expertise in something, but that is difficult to achieve and not something you want to develop while under this kind of stress.
If you’re faced with losing part of your team to a late project, suggest the Bermuda strategy instead; send 90% of that team to Bermuda, and let the remaining 10% finish the project.
Use behavior-driven development, test-driven development, and lean development practices to avoid getting your self into such a dilemma. And be a little more pessimistic when you plan.