Pair Programming

This Sprint we added 'doing more Pair Programming' as one of Sprint Goals. We found out through inspection and adaption that we can reap the most benefits out of pair programming when we tackle new feature chunky stories in themed Sprints.

Stuart Wray from Royal School of Signals published an excellent paper on Pair programming. I think every agile programmer should read it and practice the suggested mechanisms.

In this paper Stuart talks about how to make pair programming more effective. He starts of by talking about defining it - 'As a dictionary definition, I’d say that pair

programming is a technique in which two people

sit down, literally side by side, and write a program at the same computer'. Many people have different understandings of pair programming, and that kind of clarifies any misconceptions before getting into the details of it. He mentions four mechanisms and their benefits. They are Pair programming chat, pair programmers noticing more details, fighting poor practices using pair programming and sharing and judging expertise.

What we do where I work is that we use it for pretty much any kind of work. Managers, testers, designers and developers all pair up functionally and cross functionally to enhance productivity and quality at the same time.

For a feature, the team swarms a lot and does a huddle whiteboard session and extracts any unclear requirements, makes suggestions to PO, and comes up with an OO design. During this time, the team member with the most testing experience creates a test plan and the Team agrees to coding that test plan to avoid scope creeping.

Developers so far noticed that they were making better architectural choices while pairing and are optimistic about it. I personally believe they are actually going faster than they would normally go if they coded on their own. Also it creates an atmosphere of collective responsibility of the code base.

One thing which is crucial is doing it in the right way. A few important things to check for are

1. Are we using one keyboard and one primary computer while paring?
2. Are we switching the navigator, driver roles periodically during a pairing session.
3. Before starting on a pairing task, are both developers clear about the goal of the task.
4. Before starting on a pairing task, are both developers clear about the scope of the task.
5. Is one developer (preferably the navigator) checking on the scope. (time boxing)

It will be interesting to see how fast the work goes this Sprint.