The Pair Programming Experiment — Part II: The Retrospective
This is Part II of a three-part series on our Pair Programming Experiment. For the experiment, we created two teams working on 2 projects for 2 weeks. One team worked in pairs, second as solo developers. After first week teams started a new project and swapped methodologies. Read all about its setup in our first post of this series. In the third and final post we’ve focused on metrics and analysis.
One of the main reasons we’ve made The Pair Programming Experiment was to confront common opinion on the methodology with real developers’ experience. In this post we will focus on our conclusions from The Experiment retrospective. Here are the thoughts after this intense (if not insane) 2-week journey.
First Feeling — “It was exhausting!”
The first question we asked both teams After their pair-programming periods: “So? How did it feel?” And both teams replied alike: “Boy! It was exhausting!”
We stand by the opinion that Pair Programming boosts motivation. Both teams were more focused when they worked in pairs. They didn’t check their emails, mobiles, facebooks and twitters every few minutes. They were less distracted by noisy environment. Developers were much more in “The Flow” when accompanied by a second person.
But there is a price: staying focused almost 100% of time is exhausting.
Communication accelerates…
Teams noticed that in pairs it is easier to manage people that do not stick to the rules (they write bad commit messages, deploy despite failing tests etc.) It’s easier to approach a pair (“Your team broke the build”) than to bring up some troubling matter personally to a single person (“You broke the build”).
The team that was paired in the first week, developed good communication practices (both pair- and team-wise). Thanks to that they were more adjusted during their second, “solo” week. It helped introverts become more assertive and opinionated talkers be less bossy.
In pairs it is easier to manage people that do not stick to the rules.
Verbal communication wasn’t the only one that benefited. Communication through the code did that too. Code Reviews through GitHub were more frequent in the team that did “solo” programming after paired period. In the team that started with solo, “offline” Code Reviews practically never happened.
…problems escalate quicker
Members of one team had communication problems during their first “solo” week. The next week, when they were paired, those problems escalated. Some people did not feel comfortable when paired with others, and personal conflicts arose. And with agile teams, the sooner you know about things like that the better.
The developers agreed that when paired, it’s best to work with people that you feel neutral about.
Surprisingly, if you are paired with someone you feel very comfortable with, it’s easier to be distracted and turn a blind eye on time wasting. You just have too much fun.
It also turned out that pairing up with someone you don’t get along with is obviously even more exhausting, but it does not impact effectiveness so much.
Of course, it’s fantastic to work with people you like, but it’s essential to pay attention whether the positive energy is spent on productive pair-coding and not on pair-slacking.
Knowledge spreads
Both teams agreed that the biggest advantage of pairing was the speed and ease of learning.
Often pair members used their partners as rubber ducks, explaining their own code to them. Not only it helped both parties better understand the task and the solution, but also helped spread the general knowledge of the whole project. Pairing helps the team become cross-functional and silo-free.
Pay attention whether the positive energy is spent on productive pair-coding and not on pair-slacking.
On the other hand, Pair Programming might be counter-productive when both pair members are completely new to some topic or technology. This can result in too much time spent on research and head-scratching. In such case, it’s better to join a more seasoned developer with a less experienced one.
Also, pairs were much less eager to ask other employees around the company for help. They preferred solving problems themselves. In this matter, “soloists” were much more flexible, at the cost of distracting colleagues from outside of their team.
Pairs like challenges
After the experiment, both teams agreed that the optimum time they’d like to spend in pairs is “one day in a week”.
It was not unusual for one pair member to sit idle during the programming session. Sometimes it was even boring, especially when the second person did repeatable or undemanding tasks.
To maximize the productivity, work alone on simple, technical tasks. Leave only challenging, difficult tasks for pairs. Only then you’ll avoid “exhaustion” problem mentioned above and allow the team to use its brainstorming power on most important tasks.
Conclusions
Summing up the above our main conclusions are:
- Pair Programming boosts motivation.
- Working in pairs 100% of the time is exhausting.
- Pairing improves team communication and organisation skills.
- Pairing up two people with neutral attitude towards each other is most productive.
- Pair Programming speeds up learning and spreads project knowledge.
Part of our afterthoughts can be put into DOs & DON’Ts:
- DON’T pair low experience developers.
- DO mix experience levels in pairs.
- DON’T work in pairs on simple, technical tasks.
- DO work in pairs on challenging, difficult tasks.
- DON’T force people to pair program.
- DO encourage them to try it out.
DON’T force people to pair program. DO encourage them to try it out.
Pair Programming is an essential tool in every developer’s toolbox. A powerful tool. But keep in mind: powerful does not mean magical. It needs mentoring. It needs observation. It needs adjustments. It takes significant effort over time before it feels natural. Although, when implemented with care, it will bring value that will stay with the team for a long time.
