In my blog post a few weeks ago, I said that future posts would include some of the supporting practices (outwith the Scrum framework) that we can use from our.
When I first discovered agile and then introduced it to my team in 2008, pair programming was one of the first practices we adopted.
As the name suggests, pair programming involves two developers sitting side by side working together on the same code. Two developers means two brains working on the same problem. One developer ‘drives’ while the other ‘navigates’.
As Shore and Warden say in The Art of Agile Development (O’Reilly, 2008), “together, the driver and navigator create higher-quality work more quickly than either could produce on their own.”
Practically, the driver has control of the keyboard and mouse and writes the code while the navigator’s job is to think: think about what the driver is writing, think about what is coming up next, think about how this piece of code fits in with the overall design.
Coding happens through conversation. Collaborate, don’t criticise.
Swap over when you need a fresh perspective or when the driver gets tired. Make sure you swap several times a day. The following day pair with someone else.
In my experience, it’s best to allow developers to choose their own partners. Over time try to ensure that everyone has a chance to pair with everyone else. This helps the team bond, share knowledge and ‘up-skill’ everyone.
Pair programming can be fun, you get different perspectives, you share ideas, you learn from one another and with two brains working on the same problem it can help you get past roadblocks more quickly.
I remember when I first started pair programming. I felt exposed and self-conscious. I didn’t want to make mistakes… no, that’s not true, I knew I would make mistakes, I didn’t want to feel judged for making those mistakes. I often felt that the navigator saw solutions and errors quicker than I did—but that’s okay, that’s their role: to think ahead.
But we stuck with it. We worked through the discomfort and awkwardness because we saw the value in our working and thinking together. Over time it began to feel normal and the natural thing to do. As the team grew it became the norm and every user story was coded together.
Sometimes we found that we needed to pair with non-developers to solve the problems before us. We would pair (or sometimes triple or mob) with designers, content writers, business ambassadors. And we adapted this approach to almost everything we did: pair programming, pair designing, pair content-writing, pair project management, pair business analysis.
As agile practices go, pair programming is among the best and most useful for producing quality, peer-reviewed code. It was also great fun with a lot of laughter and creative ideas.
Is pair programming something you’ve done? What has been your experience? What have you found helpful? What did you find difficult; how did you overcome these obstacles?
Is pair programming something you could try in your own teams? If so, choose something that you will need to maintain (including test scripts) and take it from there. Leave a comment and let us know how you get on.
Originally published on my work internal blog.