The Bearing of a Child Takes 9 Months No Matter How Many Women Are Assigned

I quote the title from the book Mythical Man-Month written by Fred Brooks and originated from Theodore von Kármán in the unique form “Everyone knows it takes a woman nine months to have a baby. But you Americans think if you get nine women pregnant, you can have a baby in a month.” Fred Brooks made this a very popular statement in the software industry, with good reasons. The idea behind it is that adding manpower to a late software project makes it later, also called Brooks’ Law.

This is a story about where I have seen this happen and what the result became to be.

First Some Context

I started working at a company as a consultant, once started I figured this to be the most political company I have seen so far. They wanted to create a product where some stakeholders had political gain to make this product fail. They did this by holding many people accountable, but not themselves. They made sure people commit to pointless deadlines on unnecessary functionality, and it was rather impossible to adhere to the agile values. They discarded any discussion on these subjects.

Build Time!

While the backlog was filling with non-negotiable stories, the developers started working. Slowly but surely we delivered functionality, and the product took shape and became more and more useful. But soon we realized the frontend flow had problems with the overall concept of how the product should work. So the team worked on an alternative design which the stakeholders approved.

A New Frontend

The original idea was to work with the same team and slowly push new functionality in the new frontend. This worked for a little while, but for stakeholders, this was not good enough, implementation must be faster as the imaginary deadline was closing in. As the deadline or functionality was non-negotiable it made sense to rack up the number of developers in the team. So they make the assumption that frontend is the bottleneck and that we need a lot of help, so management attracted 3 extra frontend developers.

The team of 3 suddenly became a new team of 6.

What Changed?

This is where brooks law comes into play “adding manpower to a late software project makes it later”

Ramp-Up Time

Brook states it takes time for people to become productive in a new team, so-called ramp-up time. This extra worker needs time to get to know their colleagues, get acquainted with the domain, need to learn the code base, what the team culture is, what we expect of him, etc.

So when the company added 3 new frontenders, the other developers in the team were no longer working, but facilitating them to be productive. So we gained 3 developers but also lost 3 developers with a sudden priority shift to frontend, instead of deliverable functionality.

Communication Overhead Increases as the Number of People Increases

One of the constant complaints was not knowing what the other developers within the team were doing. When you add 3 new people to an existing team of 3, the communication lines went from 6 to 15. 

This leads to a loss of time in keeping in sync with all team members. 

We could have solved this with pairing or even mob programming, however, because the team duplicated this culture was no longer in place.

Adding More People to a Highly Divisible Task Decreases the Overall Task Duration

The problem, however, most of the stories were not divisible, so it ended up with more communication on being in sync with whom touches what piece of code.

Anything Else?

Because they doubled the team, a culture shift happened and led to discussions the team already been through. For example, on Trunk based development, code reviews, continuous deployment and the definition of done.

Because they doubled the team, a culture shift happened and led to past discussions on Trunk based development, code reviews, continuous deployment and the definition of done.

And Then Everything Broke

Because the team discipline was mostly frontend, it made sense to some to split up tasks for front and backend work. Which shifted away focus from delivering functionality, to finish their frontend task.
It ended up with frontenders creating a beautifully “working” application based on fake APIs, and they were happy, it looked great!
However, when the backenders try to implement the APIs based on frontend work, it became apparent that the fake APIs did not fit the existing domain model at all. We ended up with an application that looked great but had no working functionality and therefore a useless application.

If you want to grow a team, then make sure you do it for the right reasons. Brooks was right. Making a deadline isn’t one of them.