Rants, rambles, news and notes from another geek

Martin Fowler's Weblog

Martin Fowler, author of Refactoring, now has a blog&nbsp_place_holder;or something like one. He calls it a bliki… a cross between a wiki and a blog.

While reading his RSS feed I found this little tidbit:

A better approach is to try to scale down your project. At that workshop an unscientific straw poll revealed that most projects could lose about half the people of the project without making things go slower. Time and time again I hear of success occurring when a team is cut significantly in size. Large teams carry a big overhead in communication and management. Using smaller teams staffed with more able people is usually faster and cheaper, even if the everyone is more individually expensive.

I couldn’t agree more. I’ve heard people say to me, “Yeah but how can you scale XP for an 18 month, 50 man project?”

My answer has always been, “Why the hell do you have 50 people? What takes 18 months to do?”

I don’t mean to imply that there aren’t projects that actually take that long to complete, but I don’t believe in scoping projects that large. Break it down into smaller, more manageable chunks and let a smaller team go after it. They should be able to produce useful pieces that bring immediate business value in as little as a month or two. The team might still be working after 18 months, but I’ll guarantee they won’t be working on what they thought they were working on at the beginning.