Getting Pair Programming right is difficult. Only die-hards amongst us implement this successfully. Most have given up.
Programmers bringing, different prior experiences to a task, collaboratively, should deliver superior code quality, cleaner design, and consequently, deliver increased customer value. A 2009 meta-analysis of existing pair programming efficacy studies, however, conveyed more sobering results. In most cases, the additional cost (effort) could not be justified.
The underlying studies did have serious shortcomings, however. Most of these studies, that the analyses were based on, did not use professional programmers. Moreover, the studies were over an extremely short duration, usually spanning just a single task.
It’s over the longer term, that I suspect, the true value of pair-programming reveals itself. Signs of s_prints burnout_ might be visible within a single project. But, it is over several projects, that it becomes most apparent.
So what, if anything, can we do, to better wring out the benefits of pair-programming?
Pair-programming is about getting the group dynamics and psychology right. Can we use persuasion techniques to mitigate burnout ill effects? Is it possible to use neuro-science learnings, to propel programmers, as Joel (of Joel on Software) says, into “the zone”?
What can we do to go from here:
To here:
In the graph above, the closer the line is to 100% the better, obviously. Also, the graph shows the cumulative effort of the pair. So, the story points delivered to the customer, ideally, should be double that for a single programmer.
This is rarely the case. But, if your graph even looks like the one above, month over month, the extra effort is worth it. Your level-3 support team will thank you for the improved code quality, readability, and maintainability.
Joel’s “zone”, referred to an isolated programmer experiencing high levels of concentration. All expert programmers experience this. These are some of the most productive periods for a programmer. However, like writer’s block, getting into “the zone” is not easy. No wonder writers need help from a muse.
Pair programming benefits are enticing. Can cognitive psychology be used to push pairs into the zone, to deliver these benefits?
Being in the zone, for a pair, means high-intensity collaboration. That can only come when the self and group (pair), begins to blur. When programmers repeatedly imagine doing something, and then coming to believe that they have actually done it.
We applied two of Dr. Cialdini recommendations for closer group dynamics: continuing reciprocal exchange and co-creation.
In 2015, this article went viral. It was based on a study, where in pairs, participants took turns reading questions to their partner, who would answer, and who would then receive their partner’s answer to the same item. Advancing through the thirty-six questions required participants to disclose progressively more personal information. An early question would be, “What would constitute a perfect day for you?” whereas later in the sequence, a question would be, “What do you value most in a friendship?”.
The rules for our guinea pigs, oops, I mean programmers, were simple.
- Coffee-breaks were encouraged for these programming-pairs.
- No shop-talk during this break.
- All coffee breaks needed to end with the pairs asking each other 2–3 questions patterned after Dr. Aron’s question sets.
The original 36 questions get substantially personal. Ours were far less. For example, we culled out most of the questions from Set III, and quite a few from Set II. Our question sets were tinier too, just like the coffee breaks (we hoped).
The results have been astounding. As the weeks have progressed, our expert-novice pair (this combination seems to work best) have consistently beaten their previous measurements. Granted, the results are in a completely non-controlled environment. Either way, we couldn’t be happier. It felt; the programmers felt, that they were in the zone.
Cialdini suggests “co-creation” as another way to get group dynamics moving. His studies have shown that increasing manager involvement in product development, resulted in them giving the product a higher quality rating. This is to be expected. You will think highly of your own work (generally). But, an important consequence, was that, “the more the managers attributed the success of the project to themselves, the more they also attributed it to the ability of their employee”.
Product owners (and in a few cases, scrum masters too) now meet with the UX team bi-monthly. The UX team is encouraged to think aloud. The differing perspectives have added richness to these design thinking conversations. But importantly, the product owners are far more engaged. Group dynamics has perceptibly improved!
Product owners seem happier about their jobs. They are more engaged in customer conversations. This should translate into increased (perceived) customer value. Perception is reality. If the customer starts believing that the products is more valuable, then it is.
All the benefits of pair programming, and increased productivity, month over month, seems within distance. Whether this productivity bump continues? Time will tell.
If others have similar results, we may be on to something!