Fragile Agile?

How do agile teams stack up against those adopting a more conventional methodology. My focus here is not so much on the development model itself and how it lends itself to a useful product, but on the team dynamics it produces. Though I'm sure there is a connection between the two. Do group dynamics improve? Is there some new synergy that is formed between group members? Group dynamics can make or break any project team. Does agile have the answer? One obvious but big difference is the way work is consumed and acted upon by the group. Traditionally for any group to function well, members are assigned various roles or positions. At a minimum, a team or poject leader to oversee the bigger picture and direct the group. Whilst some direction in an agile group needs to be maintained by an acting person. Work is not delegated, It is acquired by members offering. Herein lies the problem. What happens in a team where not all members offer to acquire work equally? Does the rest of the team offer to pick up the slack? Do the extra tasks just get put into the next iterations backlog? This is a real problem if the team is not equally adjusted. Problem 1) - Technical diversity always effects a group. Sometimes it can be good pairing up stronger people with those less technically inclined. Sometimes it can be a disaster. In a previous article I took a look at some of the properties of a meta-model (scrumptious) highlighting; projects that are not well understood are good candiates for agile. Projects likely to incur a high amount of change and processes becoming unpredictable with the addition of new tools andtechnologies. Whilst the model is designed for this, when you factor this into problems that can still arise from bad group dynamics (agile doesn't appear to have an answer to this either) that is a lot of uncertainty. What this suggests, is that whilst agile can be a great framework given the right group and project, it is very situational. Thus agile relies just as heavily on its processes (and in some cases meta-processes) as other methodologies. Should any of those begin to crumble....the cookie begins to crack. I'm stll mainly stuck with questions at this point: What do you do half way through an iteration where somebody decides they have done enough work but the project is still behind? You can't force work. What do you do when somebody wants to work too much? Everybody should be timeboxed. Who is responsible for collating the efforts of an iteration? Everybody? It has to occur is some organised fashion. From my very limited experience I can see it potentially working well in small projects. I do not know abouts its viability in large projects though. Because the process is a group oriented process, the larger the group the harder it would be.