Delivering Better Products Through Intention Driven Pairing

Some things come intuitively in software development. Good design is good when it’s easy to work with. Well written code is easy to read, understand, and change. Good teams are a joy to be part of. And good process makes our day-to-day work more efficient. 

However, some practices do not feel right at first. Pair programming is one of them. When I first started pairing it felt uncomfortable. I felt I could get more code written if I paired alone. And I was right. 

But pairing isn’t about writing more code. It’s about writing better code. 

And it works. But if it works, how do we, as engineers, get comfortable with pairing?

A different way to pair

When I first started pairing, I did not enjoy it. As a driver, explaining and justifying my every move felt frustrating and slightly awkward. I also felt a sense of dread that my pair and I would disagree, causing us to slow down and create an uncomfortable work environment. I wasn’t confident in our ability to maintain productive conflict.

This dynamic causes an emotional drain on both parties. This often leads to the conclusion that “pairing is not for us”. When in actuality, we haven’t given it a fair shake yet. 

I realized it was important to check in with myself on the energy I felt toward pairing. This notion of subjective “energy level” is how I began to assess my progress. I’d answer the question, “how did that go”, by checking how I felt at the end of a pairing session. Did I feel drained or energized?

This question led me to Intention Driven Pairing. It was adopting this practice that led my team and I’s pairing to a new level.

Because ultimately, pairing is a practice. It is a crucial skill to practice alongside many of the other practices that make up the software development process. At Connected, our mission to Build Better Products goes beyond our own work and into helping everyone in the product community practice their skills. It’s why we’re hosting the Global Day of Coderetreat so that we can take time to focus on deliberate practice.

One of the areas we want to point this focus is Intention Driven Pairing—a methodology where a Software Developer is able to continuously receive feedback on their coding and pairing practice. So how does it work?

Overview

Intention Driven Pairing is a daily practice. It is broken into three parts:

1. Set Expectations: Start of the day
2. Work in Timeboxes: During the day
3. Close with a Retrospective: End of the day

1. Set Expectations

Beginnings and endings are powerful. We launch ships. We kick-off projects. We celebrate firsts in our personal lives and those of our loved ones. But most of us miss out on recognizing an important first that happens every morning: The start of our day.

Setting expectations is an opportunity to set the stage for the day. It’s broken into two parts:

1. Sync on tasks and time
2. Set learning goals

Sync on tasks and time

First, we review our work-in-progress work and agree on what is realistic to complete in a day. Here, we can afford to dig a little deeper than how we cover status at daily standup.

We also look at each others’ calendars and schedule a time to pair. I find the explicit commitment of booking time in the calendar holds us accountable, and communicates our intention to the team. This improves the likelihood that we actually end up pairing in the first place.

Furthermore, this approach is a realistic first step to getting a team to pair more often. We may start with only booking half an hour a day to pair. As we get better at it, we can progressively book more time. Eventually, you may become a “pair by default” team, though it’s unreasonable to assume that a team will adopt pairing in that manner in a single day.

Set learning goals

It is in the nature of our profession that we must learn continuously. Again, this step calls it out explicitly. For software developers, there is a natural tension between learning and delivering. It is important to bring it up front and center so that we can plan our pairing strategy accordingly.

For example, if we are behind on our sprint and my pair has the necessary domain knowledge to complete the work, I will propose that they “drive” while I “navigate.” I would then take notes silently on the areas of the domain I don’t understand so that I can go back and learn it. On the other hand, if we are on track, I may propose to “drive”, as it would allow me to learn the domain as we complete the work. The downside is that we would move a lot slower.

The value of this step is that we are setting expectations on how quickly we will complete the work vs. how much we learn from doing so.

Examples of learning goals:
“I want to become more efficient at coding through the use of tools and shortcuts”
“I want to get more comfortable with JavaScript TDD”

2. Work in Timeboxes

Timeboxes are a common strategy used in Agile Software Development to ensure time is used wisely. Specifically, when a timebox is assigned to a task, the task is closed once completed or once the timebox has elapsed. The only variation we employ is that we only “abandon” the timebox if both me and my pair need to switch context away from our task due to an interruption.

Here is how we use timeboxes in Intention Driven Pairing:

1. We agree on a repeatable timebox, usually 15 to 45 minutes long
2. We use a timer to strictly adhere to the timebox
3. We aim for uninterrupted focus during the timebox
4. Interruptions are deliberate and intentional
5. If interrupted, we both decide whether to switch context
6. If context is switched, the timebox is abandoned
7. After the timebox elapses, we check in with each other, and take a break if needed

One of the advantages of pair programming is that a pair of developers are more resilient to interruptions in the first place. For example, if someone approaches a pair to ask a question, the “navigator” can provide an answer, usually without the “driver” having to break context, or even focus. Therefore, an abandoned timebox should be a rare occurrence—when it happens it means that the matter is urgent enough to require both developers’ full attention.

Tracking Timeboxes

While working in timeboxes may feel rigid and contrived at first, it can unlock value over time. Especially when we begin tracking our timeboxes. How many did we complete in a day? How many were abandoned? What insights did we discover? This can be extremely valuable data for a team that struggles with focus or delivering at a sustainable pace.

3. Close with a Retrospective

This leads us to the third and final part of the Intention Driven Pairing methodology. The end of the day is an opportunity to imbue a moment with meaning. We can look back on the day and ask ourselves: What have we done? What have we learned? What can we bring to tomorrow? What should we leave behind?

The retrospective should be a personal, one-on-one with your pair. You have shared meaningful periods of your day and should reflect on them deeply together. You should be honest. And you should look to provide valuable feedback.

Even a five-minute pairing retrospective can be extremely valuable. Each individual can share their one top-of-mind item. Taking one or two items into the next day helps everyone incrementally improve their coding and pairing practice.

Examples of pairing retro feedback:
“I get disengaged when I navigate for more than three timeboxes in a row. Next time, can we try switching more often?”
“Relying on console.log really slowed us down. Next time, can we try setting breakpoints using Chrome dev tools?”

If you feel your end-of-day retros are short, don’t stress. Frequency is more important than duration. Whatever you do, make sure you don’t skip this step. Why? Because the value of the feedback improves over time. 

As we build psychological safety with our pair, we are able to share more deeply. We recognize the positives in our pair that we may have been taking for granted. And we recognize the negatives in a more open and insightful manner.

Closing thoughts (and a word of caution)

For our teams at Connected, Intention Driven Pairing started off as an experiment. For us, the experiment was a success. In our every-present mission to Build Better Products. We found that Intention Driven Pairing kept us focussed and improved the efficiency and quality of the products we built, helping us delight the end user and drive meaningful commercial impact. I encourage other teams that relate to these challenges to try Intention Driven Pairing out for themselves.

However, to quote the Agile manifesto, “we are uncovering better ways of developing software by doing it and helping others do it.”

For every engineer and every team, constantly uncovering is the sign that the practice is working. Practice doesn’t make perfect, but it does open you up to better. I invite you to keep uncovering. This means changing, tweaking, adopting, and abandoning. This is encouraged, as long as we are honestly asking ourselves:

Is it actually not working, or is it just uncomfortable?

Intention Driven Pairing only works if we live up to the intentions we set out for ourselves. So get out there and practice.