A common question is whether large projects can be done with agile techniques. After all many agile approaches are designed for smaller projects and the heavyweight ideas that they resist are more needed on bigger projects.

One of the main reasons that this is a question is because we don't know yet. New techniques tend to be tried on smaller projects first. Only when they work on a smaller scale do people try them on a larger scale, and even then it takes time to ramp up. With any technique or technology I wouldn't recommend using it on anything larger than twice the size of something you've used it successfully already.

Despite this much of what goes with agility has a background in larger systems, depending on what you call large. For software projects I think the primary measure of large is number of people. The people there are, the more the communication issues rise. XP's sweet spot is up to twenty team members. FDD looks to be more, more in the mid tens. Talking to Phillipe Kruchten, the lead designer of RUP, RUP at its essence is very much an agile approach and Phillipe has primarily worked with projects of over 200 people.

Scaling Agile methods is the last thing you should do

I used this phrase recently at the Canadian Agile Network. I meant it literally. I'm not saying that you shouldn't do large projects, I'm saying that trying to scale agile techniques up to big projects, while often necessary, shouldn't be your first choice.

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.