Does a Pair Beat an Ace and a Jack?

If your organization is like our organization, you were pair programming on and off long before attempting to adopt agile practices. Back then it was called mentoring and solving a difficult issue as a team.

For the last 6 months or so we’ve been using pair programming in a much more XP way on certain projects (driver and navigator, switching roles, etc.).

When the team is estimating work or tracking actual effort, there does not seem to be as much productivity gain involved as we had hoped. Usually the developers are saying, “Hey we like pairing, but I could do the same work myself in the allotted time and the other person could be doing something else.” One thing they all agree on is that when they are pairing they are less likely to be distracted by e-mail, phones, etc.

The biggest benefits from pairing so far seem to be mentoring and sharing knowledge, accelerated learning, cross training, better and more consistent design (depends on who the individuals are though), and perhaps reduced errors. For long running projects or products that will have a life cycle involving lots future changes and improvements, I suspect that the true benefits will manifest in the future. It could also be an experience factor or an imbalance of skills in the pair.

The literature (Pair Programming, XP Explained) seems to support 1+1 = 2 or 1+ 1 => 2. I think its achievable, I like to bet on a good team.

What is your experience? Does a pair always beat an Ace and a Jack?

By |2017-04-03T12:41:32+00:00May 22nd, 2008|Categories: Doug's Blog, Software Development|

About the Author:

Doug Wagner is an entrepreneur, President and Co-founder of Sunwapta Solutions. Sunwapta's mission is to help businesses transform from surviving to thriving, sustainable growth. From strategy to implementation, this means marketing, sales, managing your brand and delivering consistent value. Get more clients and keep them.