Agile Zone is brought to you in partnership with:

Michael Norton (doc) is Director of Engineering for Groupon in Chicago, IL. Michael's experience covers a wide range of development topics. Michael declares expertise in no single language or methodology and is immediately suspicious of anyone who declares such expertise. Michael is a DZone MVB and is not an employee of DZone and has posted 41 posts at DZone. You can read more from them at their website. View Full User Profile

Optimal pairing

11.09.2010
| 1105 views |
  • submit to reddit
What was all that rambling about Harmonic Mean?

A while back, I posted a rambling entry about the impact of Harmonic Mean on a team's performance. The post was actually about pairing. My intention was to put a solid mathematical, albeit only pseudo-scientific, explanation behind my paring recommendation, but I think I lost several people (including myself once or twice) in the math and all the fancy words.

In short, whenever you pair two people of disparate skill sets, their contribution to production is more heavily influenced by the lesser skilled or experienced of the two. And the impact is significant. The greater the disparity in skill/experience, the more significant the impact.

Pair with people of similar skill and experience

Maximum performance per pair is achieved when the pairs have identical skills and experience. This is, of course, highly unlikely. It is, however, fairly easy to put together a team with similar skills and experience. This provides us an opportunity to mix pairs, keep things fresh, and disseminate knowledge and experience more rapidly through the team without concern over the impact of mis-matched pairs.

When putting a team together, it is best to make sure the skill sets are within a few degrees of one another. When this is not possible, work to achieve a fairly even distribution of skill and experience. Avoid large gaps and do your best not to leave anyone isolated at the ends of the scale.

Exceptions to the "rule"?

The Software Craftsmanship movement encourages us to apprentice people new to software development. To bring them in, take them under our wing, and provide them the opportunity to learn through direct interaction with other developers in a structured and meaningful way.

Surely, Doc, you are not suggesting that apprentices should teach one another.


Yes, I am.

First of all, a good apprentice program does not immediately toss the new hire into a high-demand deliverable project. A good program provides the apprentice an environment where they can work on breakable toys designed to help learn fundamental concepts. Each step is a building block to the next, wherein fundamentals in both theory and practice are learned and built upon.

Under these conditions, who better to pair with than another individual of similar skill and experience? You can discuss, debate, discover, and learn all under the watchful eye and guiding hand of a more experienced journeyman or craftsman. The master cannot and should not devote his entire time to the growth of the apprentice. It is optimal, even as someone brand new to the craft, to pair with another much like yourself.
Published at DZone with permission of Michael Norton, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)