Andy Singleton says yes!
Andy says that if you accept that development will be distributed and get on with making it efficient it leads you to question a bunch of common practices.
Don't do interviews.. and Don't do estimation.. were my favorites.
Andy's company Assembla pull together a bunch of open-source and internal tools to set up a tool chain that lets lots of people work on the same project at once, gives visibility to your customers and tracks progress.
Andy also suggests that when a project is just starting up you can pile on loads of people and let it settle into a good team. This goes against my current experiences with development teams. In my experience you need to get 2-4 really smart people to do some vertical stripes through your application to flesh out an architecture. Once that is done.. then you are ready to start scaling the team up. Bringing too many people on early leads to too much code before the architecture is set. This leads to lots of code to refactor as develop and understanding of the domain.
Having said that... the initial architecture decisions you are making tend to be... How should we separate the domain logic from the presentation logic? How should we use Technology X to implement the GUI?
These things seem like such solved problems to me at the moment. I can't understand why they take so long to get in place. For each technology stack there should be something like Rails where you just fill in the bits that are specific to your domain.
Back to Andy... I'd love to hear more about how the first few weeks of his projects go. He claims to be having good success, so I would love to know more :)
I guess I'll start reading his blog.