How to Sell and Implement Pair Programming, the Middle Way
On an Excella COE distro, we recently had an interesting discussion about pair programming, and how to sell the idea to a reluctant client during an Agile adoption. Through this discussion, I learned that I believed two things:
1) Incredibly strict regimens for pair programming aren’t always optimally productive arrangements.
2) In an Agile transformation, Agile coaches and practitioners need to be careful about advocating too fiercely for pairing.
I believe that it’s generally a good practice, but I think often, the Agile community is a little too dogmatic about it’s approach to this technique. Adopting more productive pairing practices should be a goal in any Agile transformation, but I also think there’s a middle way to sell and implement the practice. Specifically, those tackling this issue should do three things: be specific about the evidence, understand the nuances, and understand the people issues.
Be specific about the evidence
This excerpt from a blog post by Katie McCroskey at Thycotic is a fairly typical assertion from the Agile community: “Case studies have been conducted, the experts have weighed in, and the results are unequivocal: the benefits of Pair Programming can result in significant advantages for an organization developing software.”
Well… what studies? What benefits do these studies prove conclusively? Are they really “unequivocal”? (Answer: NO.) There’s a lot of unsubstantiated claims from the Agile community about pairing, and unsubstantiated claims aren’t going to convince a skeptic.
If I’m Joe Waterfall with a super long Gantt chart that needs people on line items, why should I put faith in what sounds like a statement of opinion? “Pair programming is more productive” isn’t an intuitive conclusion for someone who hasn’t done it before. If you’re selling the idea, you need to bring more concrete evidence and examples.
This Cockburn/Williams study is a great piece of evidence in favor of pair programming:
Understand the Nuances
The research is not as conclusive as hardcore pair programming advocates make it out to be. Some examples:
The Cockburn/Williams study actually demonstrates that pairs suffer a 15% decrease in productivity. Notably, defects decrease 50% with pairs and pairs build better designed software, so that more than makes up for it. This nuance is important, because it might help your client get over the idea that two people can’t possibly do more work than if they were working in parallel: They can’t! Pairs do write less code than solo developers, but they write better code.
Experts are relatively less productive in pairs than novices. Teams comprised of seasoned veterans are going to get less out of pairing than rookies. This nuance is especially important to anyone in consulting. Consultants are often high skilled engineers, but we’re noobs when it comes to a new client’s systems and architecture. Pairing is especially important to us because we have a lot to learn. It’s not just about enforcing good engineering habits, pairing is about sharing system and domain knowledge as well.
The biggest benefit of pair programming is in software design, not implementation. There’s an uncomfortable implication here for pairing advocates — you get most of the benefits of a pair approach if you have an environment where developers collaborate around a whiteboard to design software. The advantages are less profound when a pair is sitting around one machine trying to get unit tests to pass. Pairing also is more productive on complex tasks and less valuable for simple development tasks.
Be Flexible, and Understand the People Issues
How common is this anecdote: an Agile expert, with buy-in from executives, stakeholders, or management, tells a software team that starting next week, they’re going to write all their code in pairs. Shockingly, there’s lots of resistance from the development team, and eventually, the practice gets shelved, or maybe it doesn’t even get off the ground.
Even if pairing were an absolute slam dunk, offering 400% gains in productivity, it will still fall on it’s face if implemented in a way that fosters dissent or reduces moral. If you’re setting out to change how someone actually does their work, seek to do it with their involvement, buy-in, and un-coerced commitment. It’s completely worth “being Agile” about implementing pairing. Work up to it incrementally and allow the people doing the work to own the pace of adoption.
The most productive software team I’ve ever served with was a dot-com I consulted at a five years ago. At this dot-com, developers almost always pair up when designing new features or debugging troublesome issues. They write a lot of code in pairs, but they also have the flexibility to go it alone, and they do so when it’s appropriate. I think this approach makes a lot of sense. Pairing is essential when working on the transactions for their ordering system, it’s not as valuable when converting fairly static classic ASP pages to ASP.NET. I believe that their flexible and developer-driven implementation of pair programming is superior to a rigid top-down mandate.
The Bottom Line
My own experience in a project with rigid pair programming requirements lead me to believe that something like the more flexible approach I described above is more productive. Certainly, if I’m writing code as part of a software team, I prefer a more moderate approach to pairing: let me pair up when we’re launching a complex re-design task, or slaying a dragon-sized defect. But if I’m tasked with changing some button colors in a bunch of CSS, give me the flexibility to get this done on my own without having another developer sitting next to me, feigning interest while checking his phone.
Having said that, I can imagine a many scenarios where that approach wouldn’t work, and a more rigid pairing arrangement would be beneficial. I can’t imagine a scenario a lack of support or encouragement of the practice at all would be beneficial. The trick is to find out what works for the team, project, or enterprise that needs to make the change. There’s probably a middle way that will elude you as long as you’re thinking dogmatically.
As Agile practitioners, we could certainly afford to be less dogmatic, more thoughtful and flexible when it comes to the direction we’re giving teams about pair programming.
