Interesting seeing agile development (SCRUM) articulated so precisely.
> Occasionally, the developed informal structure of the group coincides with an available need that the group can fill in such a way as to give the appearance that an Unstructured group "works." That is, the group has fortuitously developed precisely the kind of structure best suited for engaging in a particular project.
> While working in this kind of group is a very heady experience, it is also rare and very hard to replicate. There are almost inevitably four conditions found in such a group;
1) It is task oriented. Its function is very narrow and very specific, like putting on a conference or putting out a newspaper. It is the task that basically structures the group. The task determines what needs to be done and when it needs to be done. It provides a guide by which people can judge their actions and make plans for future activity.
2) It is relatively small and homogeneous. Homogeneity is necessary to insure that participants have a "common language" for interaction. People from widely different backgrounds may provide richness to a consciousness-raising group where each can learn from the others' experience, but too great a diversity among members of a task-oriented group means only that they continually misunderstand each other. Such diverse people interpret words and actions differently. They have different expectations about each other's behavior and judge the results according to different criteria. If everyone knows everyone else well enough to understand the nuances, these can be accommodated. Usually, they only lead to confusion and endless hours spent straightening out conflicts no one ever thought would arise.
3) There is a high degree of communication. Information must be passed on to everyone, opinions checked, work divided up, and participation assured in the relevant decisions. This is only possible if the group is small and people practically live together for the most crucial phases of the task. Needless to say, the number of interactions necessary to involve everybody increases geometrically with the number of participants. This inevitably limits group participants to about five, or excludes some from some of the decisions. Successful groups can be as large as 10 or 15, but only when they are in fact composed of several smaller subgroups which perform specific parts of the task, and whose members overlap with each other so that knowledge of what the different subgroups are doing can be passed around easily.
4) There is a low degree of skill specialization. Not everyone has to be able to do everything, but everything must be able to be done by more than one person. Thus no one is indispensable. To a certain extent, people become interchangeable parts.
> While these conditions can occur serendipitously in small groups, this is not possible in large ones.
I wonder if the originators of Agile were familiar with this work? At any rate I think it explains that dichotomy between the early developer push for agile - “we found this awesome thing that works!” - contrasted with the later wide-spread industry adoption and general hatred. I.e, the small group only works based on specific, unlikely, circumstance, and the concepts do not scale.