Has anyone actually tried "The Bermuda plan" and if so, how did it go?

Question

The Wikipedia page on Brook's Law includes the following sentence:

The Bermuda plan, where most developers on a project are removed ("sent to Bermuda") and the remaining are left to complete the software, has been suggested as a way of circumventing Brooks’s law.

(The law itself, stated briefly: "adding people to a late software project makes it later".)

The sentence is followed by a citation consisting of a link to the 7 May 1984 issue of InfoWorld, which makes it clear the suggestion is presented in a tongue-in-cheek manner.

However, I'm curious if anyone ever tried it anyway, and if so what the results were. I know it's often hard to get good numbers in project management, but if examples where a quantifiable before and after measurement was taken exist, they would be preferred.

I don't expect any organization ever literally sent programmers to Bermuda. I expect that a more likely scenario would be that some programmers were moved to a different project, (or perhaps layoffs occurred, perhaps even those spurred on by recent events), leaving a smaller number of programmers on a project.

So, does anyone know something about one or more times when a software team became smaller for whatever reason, and we can reasonably compare the quality and/or volume of output before and afterwards?

Answer 1

The three main reasons why a late project ends up later if more people are added to it are - as pointed out in the Wikipedia page:

1. The new people need to learn, so they take time away from the existing people in the team for help. So less resources to do the work while the new people become productive and actually start contributing something.

2. Communication increases. Again, less resources to do the work while people spend more time trying to find out what everyone else is doing.

3. Some work can't be nicely divided into individual pieces that can be done in parallel. One person might be more efficient at doing one task than spending time to split the task, then everyone builds a piece, then spending time putting everything back together. If you've done multi-threaded programming, you know some jobs are sometimes faster when executed inside a single thread than in multiple threads in parallel.

So let's see where the Bermuda plan might prove a possible solution:

• it helps with 3 if you have the sort of tasks that can't be divided nicely, or if you have a manager that tries to keep people 100% busy (and what better way to do that than to throw each one a piece of some larger task if other work isn't available for them).

• it helps with 2 because communication decreases and more resources go to doing the work. As already pointed out in another answer, we know from Agile that smaller teams are often more effective than larger ones.

• point 1 goes away because you don't need to train anyone. The remaining team is focused only on doing the work.

So do these points guarantee anything? No. In all three cases, the Bermuda plan only decreases the number of resources while the amount of work remains the same. We know 9 women can't make a baby in one month, but half a woman can't deliver a baby on the original schedule of 9 months either.

You get benefits from removing people only if the communication overhead and the splitting of tasks are actually the problem. Or, obviously, if the main problem for the delay was with the people that were removed from the team.

So it depends a lot on the context. If the problem and the approach to fix it match, then the Bermuda plan can be a possible solution. No match, no solution.

Answer 2

Brooks's Law perhaps needs bringing up to date. Under modern conditions team size is probably more important than the total size of a project or workstream. Lots of organisations organise their software development around small, cross-functional teams and find that multiple small teams (often fewer than 10 people) can be more productive than one large team. That has been tried many times because making teams smaller is a common theme of agile transformation programmes.

Answer 3

No matter one's belief in one or another development method, or belief in this "law," what is true with every activity is that there are an unknown number of both aleatory and epistemic drivers that influence schedule outcomes. And tasks have varying degrees of resource elasticity and a single task can have varying degrees of elasticity depending on the environment in which the task is performed. Trying to attribute goodness of an intervention--whether you increase team size, decrease it, or change a light bulb (Hawthorne)--is not an easy task and one could easily get in the business of confirming what (s)he believes is true than what is actually true. I cannot even imagine the meta, longitudinal study that would have to occur, and repeated, on a sizable project set--with a control set--with documented "reduced staff size" interventions in order to do some type of statistical tests to evaluate this hypothesis.

What you'll no doubt get are anecdotes and a severe case of confirmation bias, especially from those who are strict followers of one method or another.

What I believe is true is that we have way less control over cost and schedule outcomes than what we want to believe.