To be honest, I steer clear of such discussions, as I don't have any experience with larger teams, to make any commentary regarding these paradigms.

Since large teams have been around for many decades, now, they do appear to be rehashings by another name of certain standard techniques.

I haven't really studied these techniques and frameworks in great detail, but it seems to me that one missing element is a single driving architect. Further, while teamwork is good - teams aren't teams unless each individual is more than competent at their given task. The techniques described seem to run the risk of dragging things down to a lowest common denominator.

From all I have read, however, the technique isn't the solution; indeed, the techniques (such as Scrum) have a glaring hole - it is completely managerial based, although it doesn't look like it on the face. You need an enforcement of a timeline, and that requires time management. It looks like each technique simply chops up a larger project into smaller manageable chunks, which an individual developer can put a cost/timeline to without a great deal of experience. Rapid reassessment of current development allows management to realign and refocus on task; you basic develop/assess iterative cycle.

I'm with SH on this one, but it probably comes from being completely ignorant of the application. I generally work in an environment where there is rarely a dedicated programmer, let alone a team of more than a couple, so what I say is probably all hogwash.