Pair Programming is good for increasing the software quality and collaboration within team members. It has too many benefits but really is pairing easy for team members?
Marcos Brizeno, Computer Scientist and Consultant Developer at ThoughtWorks Brazil, shared his thoughts on why adoption of pair programming is hard, in his recent blog.
Marcos mentioned following challenges in doing pair programming:
- Infrastructure: Team should have dedicated workstations having common setup of editors, OS etc.
- Fatigue: The increased focus doesn’t come easily, it takes a lot of energy to focus on the problem, share your thoughts and hear the other person.
- Ego: It's important to stay humble and hear the other person instead of arguing.
David Green, software developer at TIM Group says that pairing is not for everyone. He shared his views in his recent blog as:
Any team will end up with a mixture of characters. The extroverts will tend to enjoy pairing, while the introverts will tend to find it harder and seek to avoid it. This isn’t necessarily a question of education or persuasion, the benefits are relatively intangible and more introverted developers may find the whole process less enjoyable than working solo.
Joe Barnes, producer of ASCII characters, mentioned plagiarism as the factor, which is stopping his team for doing pairing.
I believe I have realized the greatest factor that is killing our collaboration through pairing. It’s the indirect result of an old fear of plagiarism.
Marcos explained a retrospective exercise called “that person and this person” to concluded set of best practices of pair programming in your team. This is originally a retrospective activity posted by Paulo Caroli, agile coach at ThoughtWorks and Taina TC Caetano, Consultant Developer at ThoughtWorks.
Divide a wall in two sections, "Don't be That Person" and "This Person rocks!": In the first section, team members write an example of behavior they didn't like.The second section include examples of what people really liked.
After that, go over the wall and let the team talk about each example. The conversation should be about how the team feels regarding certain types of behavior, do people agree that this is a good thing to do? In some cases the behavior could be apparent, in others it may merit a deeper discussion.
I see this activity as a good way to boost the team morale, having this conversation usually leads to people being more open to each other, thus leading to more conversations. A good way to sense the dynamics of a team is by observing how much they talk to each other. A quiet team usually means that people are disconnected and a low amount of information is shared.