Share via

How we do Pair Programming

  • Article

Our team is responsible for developing and maintaining all of Azure Management SDK which includes quite a bit of languages and tool. For example, we own .NET SDK (https://github.com/Azure/azure-sdk-for-net), PowerShell Toolset (https://github.com/Azure/azure-sdk-tools-pr), Java SDK (https://github.com/Azure/azure-sdk-for-java), Node JS SDK (https://github.com/Azure/azure-sdk-for-node), XPlat CLI Toolset (https://github.com/Azure/azure-sdk-tools-xplat), PHP SDK (https://github.com/Azure/azure-sdk-for-php), as well as a pretty complex internal code generation platform. That being said we are a rather small team and until recently had at max 1-2 devs expert in each language/platform. That obviously presented a few issues. To gain maximum efficiency our PMs would always have to give us a diverse mix of tasks that included all of the languages and platforms. Whenever there was a big event such as //build or TechEd and the deliverables piled up (usually PowerShell and XPlat CLI got hit the worst) some team members had to work late hours while others were not really able to help. Also the daily scrums were kind of boring, since people could not really relate to what everyone else was doing.

So, to make the long story short, we have discussed at our last retrospective that our team would probably benefit from doing XP style pair programming (we have recently moved into an open space and the room setup was congruent to pairing). Since we didn’t have any XP practitioners on our team I have shot an email to our in-house Agile guru Arlo Belshee (https://arlobelshee.com/) who has generously agreed to come over to coach our team.

Here is what we have decided to do:
1. Do 2 pairing sessions a day – 90 minutes in the morning and 90 minutes in the afternoon. This arrangement gives us enough time to answer emails and review GitHub pull requests while letting us have 100% focus during the pairing sessions. By the way, pairing is intense. Doing 8 hrs a day of straight pairing will fry your brain!
2. Use the thinker/typer approach for coding tasks (not sure what is the official XP name for this) – one person types and one person thinks. The one typing is not allowed to type on his/her own. The moment the typer wants to contribute he/she needs to push out the keyboard. If both people want to “think” they need to discuss. This is by far the best pairing strategy we’ve found, which prevents the person who is not typing from falling asleep.
3. Change partners every session. That works for us.
4. Change work items every session. One person from the pair stays on the work items (if it takes more than 1 session to complete the item) and the other should go. Another rule is that a person can’t stay on a single task for more than 2 sessions!
5. Picking the right pair – initially we’ve agreed to do a mix of an expert with someone new to the area. For example someone who knows PowerShell pairs with a Java guys on a PowerShell task. This enables for the fastest knowledge dissemination. Later on, as the knowledge becomes more even, so will the pairs get more even.
6. Use the whiteboard to track work items and tasks. Before the session begins we write down all work items that are up for pairing on the board and discuss which exactly steps need to be done. The people volunteer for pairs and the names are written down on the board next to the items. Finally as work gets done, the tasks get crossed out one by one.
7. Pick easily “pairable” items, expanding the set of “pairable” items as we go. Here is a diagram that Arlo drew:
 
Initially we took just small simple coding problems that we knew how to solve while keeping a more complicated items for individual work. As time went by we started picking more complex items as well as non-coding research tasks. The goal is to make all work items “pairable”.
8. Do a brief retrospective on Tuesdays and Thursdays to micro-adjust our new process

So far we’ve been doing this approach for 3.5 weeks and based on the team feedback its working great for everyone. By the way, if you are going to try pairing, make sure to try pairing for the entire month before making the decision (Arlo’s suggestion). The first few days you will see a dramatic improvements. The 2nd - 3rd week you may start to hate it (the brain will rebel against someone always telling it what to do and will just shut down). The 3rd – 4th week is when you will get into the rhythm and will wonder how you were able to code without a partner before.

So here is where we are today. The team is now able to work on literally any codebase. Some quotes from the retrospectives have been “this is the most fun I’ve had coding in the past 6 months”, or “I have learned in one session more than I have learned in a long time being stuck doing X”. By the way, as you may imagine the main fear of our PMs has been that while we are learning and stuff we would stop delivering as many story points (2 people on 1 keyboard). The reality has been quite the opposite. We’ve started pairing in Sprint 39 and have finished more points than in Sprint 38. Now we are in Sprint 40 and have one week left to go. Based on velocity chart we should be complete if not more than at least as many story points as in the last sprint. Also our flow (we’re doing a mix of Scrum and Kanban) has become much more even. We max a max of 4-5 items in Active state, as opposed to 10-15 in the past.

So overall I would say this has been quite a successful experiment. Feel free to post comments or email me if you’d like more details on how pairing is working out for us.

Comments

  • Anonymous
    October 20, 2014
    we did 8 hrs pair at Redbox ...no time mingle.good or bad the whole group is vanished from the company :)