Pair programming has a lot of known benefits, but is it always the easiest way to get work done? Is your team on the verge of adopting pair programming? In this post, I want to talk about my experience with pair programming and suggest an activity that will help improve the benefits and reduce the risks when applying this technique.
These are a few positive outcomes of pair programming, but it’s not always a rosy picture. Pair programming does require a team with some degree of maturity, and people need to feel comfortable working with one another.
Everything is relative:
All the points that I have made here are based on my experience. They are all debatable and context dependent. Each advantage has its own cost and requirements, so they can’t be taken for granted. The best thing you can do is to talk to the team and let them choose how they want to work.
There could be situations where pairing is not really flowing and people are not comfortable with it. Pair rotation isn’t happening naturally or maybe the team is unsure if they should consider pairing at all. In situations like these, I suggest an activity that may help you figure out what works best within your team.
That Person and This Person:
This is originally a retrospective activity posted by Paulo Caroli and Tainã Caetano (http://www.funretrospectives.com/that-guy-this-guy/), but I have applied it on specific conversations about pairing and the result was really good.
You start by dividing a wall in two sections, "Don't be That Person" and "This Person rocks!":
In the first section, people write an example of behavior they didn't like. It doesn't have to be with the current team, it can be any example that they have encountered. Try to have everyone put up at least one example on the wall.
The second section should have examples of what people really liked. Again, it can be any example and everyone should put at least one example.
After that, go over the wall and let the team talk about each example. What you want to have at the end of the session is not a list of what the team should or shouldn’t do, but rather a list of best practices. That's why you need to make sure that everyone in the team talks about at least one of their examples.
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 behaviour could be apparent, in others it may merit a deeper discussion.. Avoid conversations about something being right or wrong, or very context specific discussions. This is because you need to find things that the team likes, not rules people should follow.
Seek feedback constantly:
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.
If your team is trying to adopt pair programming, schedule one-to-one conversations with people to get a better sense of how they enjoy working in pairs. Talk to the leadership to see if they are feeling the benefits of it, specially if they had to be convinced about it. Metrics like the quantity of defects found are not really fair, but can be an option, just make sure they are not the drivers of the decision.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.