What are the tipping points for team size vs process overhead? [closed]

Question

At what point in a team's growth must process change drastically? A lone coder can get away with source control and a brain. A team trying to ship large prepackaged software to local and international markets must have a bit more in place.

If you've experienced a large transition in 'process': Was the team's process successfully changed with the current members or was the team itself mostly replaced by the time the process change came? What were the important aspects that changed, were some unnecessary?

Answer 1

You are going to find it hard to get a quantitative answer to this. It really depends on how "wide" the project is. If there is one simple subsystem to work on, any more than 1 person will result in people stepping on other people's toes. If you somehow have a project with 8 segregated subsystems, then you can have 8 developers no problem. More likely, you will have several subsystems that depend on each other to varying degrees. Oh, and all of this is true regardless of the process you are using.

Choosing what type of process you want to use (spiral, scrum, waterfall, CMM, etc.), and how heavyweight a version of that process you want to implement is, is another problem, and it's difficult. This is mainly because people try to take processes that work in building construction, factory work, or some other industry that is nothing like software and apply it to software development.

In my opinion, McConnell writes the best books on software process, even though none of his books are process books, per se.

Answer 2

If memory serves me correctly anything above five people is where things get dicey. The number of paths of comunication between the team gets really large after that.

(2 people = 1 path, 3 = 3 paths, 4 = 6 paths, 5 = 10 paths and so on).

The last three places I've been the IT team went through a massive process change. Yes, you will lose people, probably some of the better ones too. it's not that they are stubborn and trying to stick to the old ways, it's just that a change like this will cause a mass amount of stress. There are deadlines to hit and a need for quality to be met. People will get confused about what process they are supposed to do, and many will fall back to the "old ways." (i've been guilty of this too I admit.)

The key to succeeding is to take it slow and in small steps. People need to take time to understand why the process is changing and how it benefits them. That is huge, if you don't take time to do this, it won't succeed, and key people will end up quitting causing turmoil.

One of the things to absolutely remember is that ultimately some turnover is good. It brings new ideas and people with different (and sometimes better) skill sets. You shouldn't try and force change onto people rapidly, but they shouldn't be a barrier either. If they don't agree with what is going on, they should either try and come to a middle ground with the people making the process or leave. One of the real eye openers I learned at my first job is that in reality everyone is replaceable. Someone will eventually be able to step in take the reigns.

Answer 3

In my experience this transition occurs at exactly the moment at which you also need management. It is hard to get above 8 developers without some over-arching coordinating function being in place, whether it is a team lead, segregation of tasks or old fashioned management. The reality I have witnessed is that even with the best, most talented, most bought-in developers you still need coordination when you get above 8 working concurrently.

And there is a discontinuous step in process as you cross that boundary. However it needn't be catastrophic. The best approach is for the team to adopt as much formal process as it can when still small so that all the necessary behaviour and infrastructure is in place. I would argue that this is synonymous with good development in any case, so even the lone developer ought to have it (source code control, unit tests and coding standards are all examples of what I am talking about). If you take this approach then the step up in process when it occurs is not so much a jolt as a rigorous coordination.

Every developer you add need to be brought in with the process already in place. When you get to 8 (or whatever the number turns out being for you) then you'll find that your team meetings get a little too loose and wordy, personalities start playing a part and it is more effective to divide activity up. At that moment your boss (or you if you are the boss) will need to appoint one or more coordinators to distribute and control work.

This process (should) scales up as well if you stick to your processes. Teams can sub-divide or you can bud teams out to perform functional tasks if necessary. This approach also works regardless of the methodology you have chosen for your project management, be it Agile or not.

Once you get up to 4 or 5 teams, i.e. 30-50 people then you will almost certainly need people who are happy that their sole task is coordination.

If you are small now and contemplating or expecting the complexity shift, then make sure you get your fundamental processes nailed down immediately and certainly before you start adding more staff.

HTH and good luck

Answer 4

A lot depends on the people working on the project, the integration points, etc. Even a single coder should have a code management tool and needs to interact with clients or the 'boss'. From experience, I've seen a change once there are more then 2 people and then probably any increase of 50%. If teams are organized by project teams, focused on decoupled parts of the product, the overhead increase will not exponentially increase as the team size increases (project vs. matrix organizations).