On Teams

latest-small-64Software is so often built in teams that there a whole bunch of theories and statistics that have been generated based on the various aspects of team work. What’s the best team size? How do teams work best together? How often should they meet? and on and on…

What do I know about teams, well not much to be honest, I hate them for the most part. The problem with teams is that as soon as you put more than one person on a project or module you lose the productivity of N people. For instance,

1 Person Team = 1 productive

2 People Team = 1.9 productive

3 People Team = 1.7 productive

And so on. Each person you add to a team doesn’t add a full person, and it gets exponentially worse – the bigger the team, the less you’re actually going to get out of each person because they have to cope with communication, personality and view point issues. Engineers are a valiant lot, they love to debate and make their case. Thats brilliant! Apart from when you’re trying to get something done.

Of course, sometimes the project is just too big to allow one person to fit it in their head or get it all done in time. Bare in mind the above – thats not as often as you’d expect, that said we all end up having to have teams. So what can we do about it?

Well Scrum would tell you its all about structured regular communication. Waterfall would tell you its all about designing everythink to infinite detail up front to prevent any sort of discussion. I think theres a few tips that can help:

  • Module/Section Ownership – each team member “owns” one of more modules of the code. i.e. it’s not a free for all within that module. This can sometimes lead to bottlenecks, but also means that one person has authority and responsibility for one section working.
  • No Hippie Communes – this is software, this is business, this is work. It isn’t about everyone feeling great about each and every decisions. Make sure that some one is in charge and has the authority to push through lengthy discussions. A lot of time can be spent trying to find an answer that everyone agrees on when the impact of the decision doesn’t warrant it.
  • Think Personality – Engineers are awesome, the personality range is huge, but when you’re building a team remember that. The personality interactions are often more important that the technology implications on the road to getting it done.
  • Enforce Caring – I know, that sound silly, but set the example and show that you care about your modules. Be defensive. Be forthright. Try to encourage others to understand responsibility for their own code makes them accountable for success and failure. A team that gives a shit is always a success. A team that doesn’t may succeed through luck.

Software emerged from a lot of open minded, free thinking individuals that some may refer to as tree huggers. Unfortunately that mentality creeps into our every day developer lives. Good teams argue and defend, but they don’t do it for very long.