Scenario:

Project manager Timmy receives another email from his boss. “We’ve got the go-ahead for software project ‘apples.’ It’s a big project that will take months to complete with a handful of developers. We need to fatten up the programming staff or we’ll never finish in time and we’ll get fired! omg!”

Timmy, having worked on numerous software projects, knows that getting more bodies probably won’t help the project get completed faster. In fact, it will probably make things happen far, far slower.

Aye, but where’s the rub?

The more people involved in a project, the more communication is required to keep everyone up to snuff on things. Communication has to happen between more programmers, project managers, designers, etc. In the end, more time is spent on talking and going to meetings than coding and getting things done… productivity drag, anyone? As Steve McConnell, the author of Code Complete, points out:

Communication flows more easily on small teams than large teams. If you’re the only person on a project, communication is simple. The only communication path is between you and the customer. As the number of people on a project increases, however, so does the number of communication paths. It doesn’t increase additively, as the number of people increases, it increases multiplicatively, proportional to the square of the number of people.

What’s the solution for our friend, Timmy?

We suggest keeping the team for project ‘apples’ lean and focused. Cut out as much fat as possible. Protect the team from looming productivity killers like staff meetings, status report filings, and support tickets. Oh, and load up the team with a free supply of Mountain Dew! A small team of developers, run correctly, will out-perform a large, cumbersome team… hands down.

What if his higher-ups aren’t down with the small team philosophy? That’s rough! Timmy could try pointing them at the plethora of pro–small–team evidence already out there.

BrightMix = Lean!

Dusty and myself have both worked in large development teams and… well, we don’t like it. We like the flexibility and low overhead that our lean-ness gives us in the software development process. Honestly, though, this is the subject for another whole blog post!