Furthermore, if you have a very capable team, you may not even need a formal "Methodology".
Furthermore, if you have a very capable team, you may not even need a formal "Methodology".
(This actually perfectly matches my experience. A good team can work in spite of a methodology; a bad team won't work regardless of the methodology.)
Once you break a project down into subcomponents that interact, you need to coordinate release of any changes to interfaces, so the work of one team doesn't break the work of another.
I actually have had the experience of leading a team of 50 developers in a 120 people project. We all were the new on the project and didn't know each other, I basically picked the most qualified 7 developers and formed teams. We broke the project into modules and look for smart ways to work and not stepping over each other.