The difference in your Agile and pair programming examples is that those interactions are fundamentally between people with similar abilities. In business, the teaching, listening, and understanding are communication between people with similar baud rates. My impression is that you may be projecting your experiences with groups of competent engineers -- who all passed a rigorous screening process and years of performance reviews -- onto the behavior of children drawn at random from the entire population.<p>Group projects are a tool to adjust the average performance, without any effort on the teacher&#x27;s part. The effect is more insidious than a simple numerical average would suggest because group projects introduce a time differential. Consider people as an op-amp. Their internal drive to produce a given quality is the reference voltage. What output the currently have (the progess towards the objective) is the input. When you put top performers in a group to pull up the slackers, the feedback gain of that system is artificially reduced. The good students want a certain level of quality, so they will work even harder to try an bring the quality (input signal) up to their standards. Depending on how bad the slackers are, the good student may even reach saturation, running out of hours in the day to compensate for the incompetence of others.<p>The incompetent teachers intuitively understand this effect. They are not fostering some kind of social nirvana, they are transferring the workload of pulling up the class average onto the bright kids. The bright kid ends up spending twice, three times as long on the group assignment, and that effort gets averaged out to the other group members&#x27; grades. The cost to top performers is all that time they could have been improving, moving forward, was stuck doing large amounts of low skill work.