Inefficiencies and large teams

When is it profitable for a team to grow? Do we really need big teams to handle big projects?

I deplore the fact that so many people measure the importance of a software project by the sole size of the team working on it.

Many members certainly imply more brainpower potential, but also a greater difficulty to realize this potential. Actually, I notice two common pitfalls for crowded teams, namely miscommunication and lack of motivation.

I witnessed 7 years ago a big telecommunication company hiring hundreds people worldwide for developing the OAM (operations, administration and maintenance) system of the 3G cellular network. The project lasted for more than 7 years, during which the 3G cost center was largely off-balance. The teams communicated poorly, and the development was overall running slow (often behind schedule). Finally, the 3G business was sold to a competitor... what a waste of energy, isn't it?

At the time I had the incredible chance (though I prefer to believe this wasn't only due to luck) to integrate a small team directed by talented people, who were advocating the adoption of XP methodology ; thanks to their competence and a well-conducted presentation, they managed to convince directors to experience XP on a sub-project. We achieved it in one year and 4 team members, and the quality was clearly above expectations.

We then wrote another success story with a second sub-project, much bigger than the first one. It took us 2 years to have a useful product, and 3 more for incrementally making it really great to customers. The sense of product ownership and the freedom to adapt and refine our process allowed these years to become an exceptional experience, in spite of the heaviness of the environment (the organization reflected a huge waterfall model for 90% of the project).

I remember though that this wasn't that easy to make it happen: on the second year, the management decided that the team wasn't moving fast enough, and the team grew directly from 3 to 12 people in a matter of 3 months. The project barely survived this electroshock: the newcomers mostly didn't understand the XP values and principles (some were even opposed to it at first), and we were honestly too few and unprepared to integrate them all in such a short time.

As you can guess, the disorganized and inexperienced team was very quick to mess up the existing code design, and our self-confidence was beginning to drop dramatically... this is a lesson I will never forget: do never abruptly impose new members to a team, whatever your reasons. More generally, forget about setting the pace of your team from outside, and focus rather on helping them find and take the initiative that will optimally elevate their capacity.

The early awareness of the crisis seeds and the quick reaction of the coach fortunately saved the project ; the application was big enough to define two distinct working areas, and every member, depending on his aspirations, had to decide to either work on the application kernel (entailing HMI, core concepts and transversal functions) or on business plugins (wizards, checks and operations reflecting all the 3G business logic). Mmmhh... isn't specialization an anti-pattern of Agile and XP, might you say... well, in our case, the split resulted into two XP teams working much more efficiently and collaborating very well with each other. I strongly believe that their small sizes were crucial factors in this trend reversal.

There are other concrete examples of how people hiring can badly harm even healthy projects... and sometimes there is no such happy end to the story. Usually, the same logic applies less brutally: the project blindly welcomes new members in a continuous flow and nobody notices the trap.

For knowledge work, managers should always require the active help of the established team to determine if hiring is a good or a bad thing for the sake of the project. If you were responsible for a project, you wouldn't want to end up with an desynchronized, irresponsible and poorly motivated team, would you?

Sadly, the team size is sometime a pride for carreer-oriented managers, that are tempted to use it as a lever for granting them more power and budget. Every company should fight this tendency with no mercy, even if I feel it represnts a tough task to big corporations...

Maybe a good start could be to read the excellent book "Maverick" by Ricardo Semler, in which he is advocating the involvement of every actors in the enterprise success. To overcome the inefficiencies inherent to big corporations and inspire "cathedral builders", he suggests the "amoeba approach", frequent job rotations, rounding the pyramid... there are plenty of ideas in there. I highly recommend reading it.

Here are a few quotes from his book, that I especially liked :
- "Economies of scale exists, of course, but it is overtaken by the diseconomies of scale much sooner than people realize"
- "Bureaucracies are built by and for people who busy themselves proving they are necessary, especially when they suspect they aren't"
- "Fairness for employees is like quality for customers: it takes years to build but collapses over a single incident"