More!

Since the advent of the industrial age, we have had a terrific word: “more.” It really worked for everything. When our roads became crowded, we built more roads. When our cities became unsafe, we hired more police officers, ordered more police cars, and built more prisons.

This is the introduction for one of the chapters of the book I’m currently reading, Information Anxiety, which talks about how to live in a world where we don’t have time to retain all the data that is thrown at us.

What I’ve found interesting about this sentence is how it can be applied in different areas, from police officers, like stated above, to software development.

It is surprising to see how many people that work in the area believe that a software project running behind schedule can be solved with a simple measure: throw more people in the team.

It is so appealing that nobody thinks it can go wrong, and they often forget to consider some minor points, like:

  • time it takes for newcomers to understand the project and its domain
  • time it takes for newcomers to know the people in the project
  • the decrease of communication levels brought by the addition of new nodes

and more than often, the same persons that believe in this measure forget to take a look at their team in order to really try to understand the root causes of what is happening, in a totally anti-genchi-genbutsu way of solving problems.

In a recent project I’ve participated, 4 persons were added to a 3 pairs team in order to try to increase velocity the team was delivering. Needless to say that in the first week we had a 5-pair team with 4 newcomers, and if you looked at the team room, you could see that in each pair there was one person trying to explain to the other how the system worked.

It is pretty straightforward to understand that the team was in reality less than half strong, and that in the first iteration we delivered…. guess what? Half the points.

So if you are thinking about ramping up, think again, and again, and again, and spend some time just looking at how your team works before you make any decision.

5 comments
  1. Very interesting. Sometimes less is more. In software development comunication is something essential do have the work well done. That’s why agile methodologies advice us to have small teams. Receive people in the middle of the project is something that have to be well studied before… It can mean a strong impact.

    Good post.
    Cheers.

Follow

Get every new post delivered to your Inbox.

Join 836 other followers

%d bloggers like this: