Unfair advantages

In my agile training classes, I run an experiment wherein people try to estimate and deliver work in a very short time box. I typically run three iterations, so teams can learn from their experiences and experiment with different work styles. I do not give them guidance, but allow them to seek their own paths and then I tabulate the results.

To the team with the highest "score" at the end of the iteration, I ask what their competitive advantage is -- how they managed to get more done than their peers. Oddly enough, the answers tend to be the same no matter whether I'm teaching programmers, test engineers, or high-level executives.

Here is the summary:

1. Teamwork.
   Pairing and tripling the people on a task means that more gets done sooner. Teams relying on individual work assignments consistently underperform compared with their teamwork-ing peers, and often deliver nothing at all until they also adopt team-based work.
2. Smaller Tasks.
   Winning teams trim only start work that can be completed in the time box. They find that they can achieve more points worth of small tasks than they can large tasks. Possibility this means merely that humans naturally underestimate large tasks, but the results seem to be pretty consistent so far. Doing less, faster seems to be one of the tricks that bring success.
3. New Perspectives
   Teams that swap out partners tend to complete tasks quicker. They believe it is because any two people can get stale looking at the same problem for a period of time, but a new perspective can find solutions that the others hadn't considered.
4. Superior Skill
   The tasks I give to simulate programming are puzzles. Sometimes a team has a member who is expert in solving a given kind of puzzle. The pair or triplet that contains an expert is quicker to complete their tasks than those who do not. Sometimes 1/2 the team's score comes from the expert and her partners.

This is not a scientific survey using skilled full-time developers over the course of weeks or months, and I'm willing to admit that the context of a simulation may not fully map to the real world of software development.

But what if it did? 

How much further could your team go if they were to sieze an unfair competitive advantage of backlog grooming, pairing, swapping pair partners, and continuously developing their skills? What if we could do the same thing at other levels of the organization, above the scrum teams?