Software projects work better with small teams.
On the other hand, it makes sense to have multiple teams of workers if you're paving a patch of highly trafficked highway.
Three reasons:
Coordination
Learning
Ramp up time
As we learned from the Mythical Man Month more than fifty years ago, software projects rely on coordination of work. As you add programmers, the work doesn't go faster, it gets slower. Ramp up time is expensive. And if the project involves learning as you go, then big teams waste far more time at the beginning while you're figuring things out.
On the other hand, it doesn't make any sense at all to have a single crew working on a paving project. If you need to close the road for two weeks as they work from one end to the other, you've cost the users of the road a fortune. Ramp up time for trained professionals is trivial, and there's no learning and not much coordination. Better to have five crews working on different sections and open the road after just one or two days.
Often, we default to a small crew because we don't believe we can afford a bigger one. But if the work is worth doing, it might be worth doing more quickly. It's easier than ever to find ways to scale project labor now.
And sometimes, we mistakenly choose to use a big crew, thinking that nine women, working very carefully in coordination, can have a baby in one month. Wishful thinking that ends up in disappointment.
If you want to see a project in trouble, look for how crew size was decided.
from Seth Godin's Blog on marketing, tribes and respect http://feeds.feedblitz.com/~/547601922/0/sethsblog~Big-crewlittle-crew.html
No comments:
Post a Comment