Pair Programming Experiment

As part of my teams' modernization of our application, we hired an outside company to help us deliver faster with their defined processes. One of these defined practices was pairing Michelin development engineers with their development engineers.

It sounds crazy to put two engineers to work on one development feature. Wouldn't it be faster to split up these two engineers and deliver the feature faster? We decided to follow these defined processes for the next 16 weeks to see the value add of pair programming.

What is Pair Programming

Pair programming is the practice of two engineers working together to deliver software features. Pair programming is one of the practices of Agile Extreme Programming (XP) styles.

See Martin Fowler's article on Pair Programming which clearly outlines all the steps in this pair programming style.

How Does Pair Programming Work

In today's world of remote work this means that the two engineers will be online talking with each other via Zoom, Teams, Slack or other screen sharing apps. Michelin uses Microsoft so we really wanted to use Teams. Our team had 4 engineering pairs, 1 product manager pair, 1 design pair and 1 architect pair.

We experimented with Teams using one large meeting for the day and create several breakout rooms. However Teams is limited on the number of managers to the breakout rooms so we couldn't switch easily between the rooms to talk amongst ourselves so we used Zoom on the web for the break rooms. After the 14 weeks in our engagement, we attempted another experiment with Teams to create separate channels for each of the pairs. We had 4 separate rooms for our 8 engineers, a room for the 2 product managers and a room for the 2 designers. This worked better for our team allowing us to use Teams. It allows us to switch to other pairs meetings rooms to talk about solutions and allowed us to have the discussion chat stored in the channel for the pairs for future use.

One engineer of the two person pair will be the "driver" while the other is the "navigator". The driver is the person who is actively writing the code. The navigator observes, checks code for accuracy and keeps an eye on the "big picture".  The pair of engineers would talk about the solution and agree on approach of how to write the code.

There would be an separate person in the group of engineers pairs that would be the "anchor". This anchor would be the decision maker if the team needed neutral party to make decisions. This anchor could be the architect or another engineer in the group.

The groups of pairs switch roles regularly usually every day with other pairs to keep silos from occurring and to allow all engineers to have knowledge of the entire application including the DevOps work of the CI/CD pipeline. The anchor could also switch daily or weekly if the team does not have an architect. For our project, we had a defined anchor for the entire 16 weeks.

The team would have a daily morning standup talking about what they did the day before and any issues they had. After the standup the engineers would stay on the standup call and decide who is pairing together using a tool called parrit.io. They would discuss any upcoming stories that needed more technical design or any questions on their issues they might have had.

During the day the pair would work together on the story ensuring they had frequent breaks and a defined lunch period. At any point in the day if the pair needed assistance from the other engineers they would switch breakout rooms to another pair of engineers to ask for advice or assistance on their issue.

At the end of the day the pair would check in their code to their feature branch.

Tools We Used With Pairing

• Collaborative tool to talk and view the work such as Zoom or Teams. Breakout rooms work great for allowing all engineers to switch rooms and ask for help or advice.
• Tool to record the feature and pair working together. We used parrit.io. It allowed us to record the Jira user story with the team working on the feature.
• Tool to capture the user story such as Jira.
• IDE plugin like Code With Me or Visual Studio Live Share.
• Digital Whiteboard for drawing designs. We used Miro for this.
• Location for storing Architecture Decision Records (ADR) when made by the team if it doesn't already exist. We used Git with Hugo server to create a documentation site.
• Location for storing technical documentation. We used Miro for collaborating on designs but I do not recommend Miro for this as it could be hard to find the designs if the board is busy and not organized. It would be better to copy the designs to SharePoint or Word doc to keep organized.

Why Use Pair Programming

Our team found many advantages and challenges to pair programming. We hope to reduce the number of challenges we found to pair programming by rearranging some of the meetings to reduce context switching and reduce the number of hours of pairing so the engineers can have time to research and learn.

Advantages

• Increases knowledge functionally and technically for team members
• Better code quality. Two individuals working on the same piece of code would be active code review. This works great if the pair is not multitasking.
• Information flow and team dynamics is increased
• Less coding defects
• Features are owned by the team and not by individual backend or frontend engineers
• Encourages active listening and engagement
• Collective coding solutions

Challenges

• Mentally exhausting when starting out pairing
• Limited time to research issues on an individual basis
• Limited time for trial and error on an individual basis
• Feelings of inadequacy when asked to code something you have limited knowledge in
• Collaboration could become intense meaning that after a set length of time differing personality styles could cause collaboration issues.
• Learning curve could be sluggish if you are a kinesthetic learner.
• Death by meetings. Too many meetings during the pairing day could cause the engineers to lose focus.
• Power dynamics. We had several individuals who led the decisions of the pair reducing the efficiency of the overall pair

What Worked

Pair programming worked great for our team because we have several newer members of the team who didn't know the application functionality. Several of our engineers were stronger in frontend development than backend development so the pairing and switching of features allowed them to get comfortable with backend development.  

I would recommend pairing with new team members. This gives them the opportunity to learn the application functionality, learn how the team is organized and allow the rest of the team to work together with the new team member to get to know their style of working.

Toward the end of the engagement, we rearranged many of the meetings so that the meetings were the first part of the day and very end of the day so there was less context switching from pairing to meeting times.

What Didn't Work

Several of our engineers who were learning new features of backend development or cloud native patterns indicated that they were exhausted and had no quiet time to read on the new features being explained in the pair of engineers. They spent up to six hours a day 5 days a week working together. This led to very fatigued individuals.  These engineers wanted some quiet time alone to review the code, do individual reading or just "play" with the code without someone always leading the conversation.

Several of the engineers were new to Michelin environment and they lacked some of the skills for backend development. These engineers were very uncomfortable working with another pair to learn new development languages. Before the end of the 16 weeks we lost one individual to another company even though we knew there would be a skillset disparity between our Michelin engineers and we were willing to upskill them with this project.

Being remote in a several time zones was also one of the difficulties we had. Most of our team was in the US time zone and we had one individual in CET time zone and one in IST time zone. This time zone difference added additional fatigue to the individuals working in pair programming.

What's Next

Overall the general consensus is that pair programming was valuable for new development features and new team members. Since our team was divided by roles into DevOps, engineering and support, pair programming added value to our team allowing each role to learn and blend our team into a true DevOps roles. After our team is upskilled in all functionalities of the application, it would be pragmatic for our team to re-evaluate the use of pair programming to ensure that pair programming is still advantageous.

Currently we are still trying to figure out the right combination of pairing rules for our team. Perhaps we only pair 4 hours a day or pair 3 days a week instead of 6 hours/5 days a week. Perhaps the pair switches during the day from "driver" to "navigator". It may be that we keep a pair together for several days instead of switching daily.

We are still learning what is best for the team and experimenting with several different approaches to pair programming.