Pair Programming and Mob Programming Rules and Best Practices

A simple guide on how to do it right

What is Pair Programming (PP)

If you have being a software developer for sometime you should probably have heard about Pair Programming. If you are not sure of which are the best practices and techniques, read along while I try to help you implement them in your team.

Basically, PP is two people writing, debugging and exploring code together. In theory is simple but is also hard because is a skill that needs practice to be developed. Normally there are two roles on a PP session: driver and navigator (imagine a rally car team), which are meant to be switched regularly. When to switch roles will depend on rules that the involved people define before starting a PP session.

Let´s discuss some techniques

Pin Pong pairing: this technique revolves around TDD since it follows the RED, GREEN, REFACTOR cycle.

1. A person starts on the driver role and the other on the navigator role.
2. The driver writes a failing test (RED).
3. Driver and navigator switch roles.
4. The new driver writes the implementation that makes the test pass (GREEN).
5. The driver refactors the code (REFACTOR).
6. Repeat from step 1 this time switching roles again.

The most important thing is that one person doesn’t get stuck writing just tests, implementing or refactoring the code. Usually, each switch occurs every 5 to 10 minutes.

Pomodoro pairing: this technique is based on Pomodoro technique that states that for every 25 min of work you should take 5 min of rest and the fourth time that the cycle repeats you should take 15 min of rest.

1. Start a Pomodoro timer.
2. One person takes the driver roles and another the navigator role.
3. Take 5-minute break after Pomodoro is done.
4. Start another Pomodoro.
5. For this new Pomodoro switch roles.

This is good for people that are not used to do PP and have it difficult at switching roles frequently.

Strong style: this technique was discovered by Lewellyn Falco who states that:

“For an idea to go from your head into the computer it MUST go through someone else’s hands”. This translates into PP as the driver just types and implements the ideas and solutions from the navigator. It’s important to don´t forget switching roles regularly since the driver (person who is typing) can get frustrated. This technique is useful when some of the participants is disengaged or not motivated in the session.

Digging for gold/Yes and…: this technique is especially useful to move things along or when things get stuck either because there is a disagreement between the two person involved on the session or because both are out of ideas on how to solve the problem or found a good solution.

1. One person generates a simple and, most of the times, incomplete idea to solve the problem.
2. The other one tries to elaborate on that idea and add to it in order to cover other issues.
3. Keep trying to improve the idea until both are satisfied with the implemented solution.

It’s important to add code during the process to improve the original idea as opposed to shutting down the idea for not being good enough. Is valid to abandon the idea once both have figured out that there is nowhere else to go with it.

Retrospective & prospective: a prospective is like a retrospective but happens before starting to work and is really good for definition and clarification of the work that needs to be done. This technique is most useful on these scenarios:

• Set goals for the pairing session.
• Talk about any action items from previous pairing sessions.
• Chat about non-work stuff.
• Plan the work ahead.

A retrospective is like a prospective but after the work is done. Is really recommended so both participants are clear about the work that was done and what is missing for future sessions. Is really useful on these scenarios:

• Check-in on how you’re feeling and clear any tension or emotions that may have arose during the PP session to facilitate the collaboration in the future.
• Decide if the goals of the session were achieved and note what was missing in order to achieve them.
• Think or discuss what could be better for next session.
• Generate action items for next session.
• Celebrate wins.

Mob Programming (MP) = pair programming on steroids

The most literal manifestation of mob programming is when a computer is shared between an entire development team. As with PP the objective is to regularly rotate the driver to keep the group engaged giving equal time to each participant at the keyboard. It can be combined with any of the PP techniques discussed above to enhance the session.

Some of the rules for the session to be productive are:

• Turn off phone notifications and put it on your pocket.
• Step away from your keyboard and be present on the session.
• If necessary, a member of the team can go away for some minutes to solve a request or take care of other responsibility.
• When creating the PR all members should walk through the code cahnges together in order to find possible issues or problems before merging it.
• The real value is not to increase the velocity of the team but to increase the overall quality of the solution implemented as a team.
• When a conflict arises, the team should arrive to a consensus of which route to take.
• Try not to go into rabbit holes or discuss trivialities too long.
• Give space to the person at the keyboard to feel comfortable and get through the thinking process to implement the solution.

Benefits of Pair Programming and Mob Programming

Using these techniques have a lot of benefits for software development teams, some of the more noticeable are:

• Ideas and solutions are double checked and improved during the coding process before achieving the final solution.
• Less time on PR reviews and work redo since they are done in group.
• Build a more collaborative team and ideas to be nurtured by everyone.
• It increases the speed of development and more importantly the quality of the code.
• It creates more interaction spaces between team members solidifying the team awareness.
• Enforces the dissemination of information and knowledge of the project among team members.
• It builds trust in the group.

Let’s mix things up

Now that we have some idea about PP and MP let’s mix things up to define our work statement for these kinds of sessions. These rules should be discussed in the team and can be modified/changed between sessions.

1. Before starting to work the team should do a Prospective so everybody gets in context of the task at hand (10 to 15 minutes).
2. The team should divide the task into smaller subtasks to be completed during the session (5 to 10 minutes).
3. Start a Pomodoro so that the first driver in the mob will have 25 minutes at the keyboard.
4. The first driver should be selected and preferably will implement a subtask not defined by him.
5. During the Pomodoro the rest of members can annotate or comment on small changes to be made like coding guidelines, small implementation changes, etc. Always aim to interrupt less as possible to the person on the driving position. The navigator should be the one guiding the driver in case is needed.
6. The driver can ask for help or a second opinion at any time.
7. After the 25 minutes are done, take a productive break of 5 minutes to discuss improvements to the work done and the next subtask. If a subtask is finished before the 25 minutes are done continue on the next one.
8. Switch the driver and put the previous driver on the navigator role and start a new Pomodoro.
9. On the fourth Pomodoro take a productive break of 15 minutes to do a Retrospective of the work done and the work that is pending or subtasks not completed. It’s also very important to ask everyone how the session is feeling so far and clear out any negative emotion on the team.
10. If the team get stuck implementing the solution, start the next Pomodoro as a Digging for Gold/Yes and… session.

Final considerations

Is really important to be flexible with these sessions of Mob or Pair Programming, especially at the beginning since this is a skill that should be mastered over time. To help you guide you and your team through this journey take the following notes into consideration:

• Pause the timer during discussions so each driver gets the same amount of time at the keyboard.
• When switching the driver, the previous driver should commit and push the code into the repository. If you are working remotely the next driver can pull the changes and start from there.
• Refrain yourself of interrupting continuously the person that is on the driver position.
• Once the driver is switched the previous driver becomes the navigator this time around.
• Avoid the “mob smell”: This occurs when a mob member works independently and wants to show the group their screen. In these situations, they’ve almost always lost the contextual thread of the mob and have just become another problem for the team to deal with, kind of like a code smell.
• Allow any member of the group, that is not the driver or navigator, to step away at any time. Giving team members the freedom to step away from the mob to deal with outside distractions helps the rest of the mob maintain focus.
• Define a facilitator that will take some notes during the hole sessions of decisions or things discuss so the team doesn’t incur into FOMO (Fear Of Missing Out).
• Suggest changes or improvements doesn’t dictate or impose them.
• Although there is no maximum of people allowed in a mob around 6 person tops seems to be a sweet spot to keep balance between work done and discussions along the coding.
• Don’t MP or PP for everything, choose carefully the scenarios and tasks where to apply these techniques so the team can benefit from these sessions.
• Put less experienced engineers more frequently on the driver position so they thrive and gain experience and confidence on their skills.

I hope you put some of these techniques in practice in you team. Wanna do a pair programming session with me?