Pair-Programming — How To Increase The Code Ownership In Your Scrum Team

The art of getting things done with quality


Maria Chec

3 years ago | 8 min read

Have you ever been in a situation of having many things started and nothing finished? Starting new things feels good, we have the motivation and enthusiasm to accomplish something new. You can still imagine how great it will be when things are finished. But then we lose the motivation or get frustrated and we stop and look for something new to start.

Today I’d like to talk about pair-programming styles and the art of getting things done with quality.

Click here for the video.

Pair-programming is good, m’kay?

Pair-programming is good, m’kay?

My feeling is that we frequently talk about pair-programming but it reminds me of the South Park’s quote “drugs are bad”, we say we should do it but rarely talk about the “why”:

“Pair-programming is good, you must do pair programming, m’kay?”

Wait, but why? What does it mean in practice? And what are the techniques and styles to follow?

Let’s talk about how working on fewer things can bring us closer to getting them done. And why having multiple people working on the same thing is better than having multiple people working on multiple tasks.

Serious stuff is done individually, not in pairs

Wasn’t it at school where we were taught an individual approach to work? At least that’s my experience with the Polish education system. Studying, work, it all is serious when done alone. Working or studying in a company is more like partying than actually getting stuff done.

I also remember that you get a better grade when you at least write something on a test. You don’t need to finish any of the questions or exercises to get some percentage of a score. So theoretically, you can get away with getting nothing finished — just partial answers to all of the questions.

This is my hypothesis on why the processes of efficient work seem counterintuitive to us. Kanban’s principle of “Stop starting, start finishing?” Oh, come on! Where’s the fun of it? We like starting new things. Who has the patience and perseverance to keep on working, overcoming the obstacles, and finishing everything?

Working in silos

Working in silos. Photo by Jim Witkowski on Unsplash
Working in silos. Photo by Jim Witkowski on Unsplash

This pattern is also happening at work. Especially in programming, we even created different roles to finish something. We have Devs, QAs, and Release Owners. The Developers develop and leave it to other people to finish off. Then they find out it doesn’t work, so they take it up again and try to fix it and give it to others to verify and so on. And it seems normal to us. We got specialized and we are very proud of our specialization.

I started thinking about it because wherever I go, I see people working individually and in silos, as a default. I guess it seems easier: you know what your responsibility is and you have total control of what you are doing. It might also seem more “economical” for one person to take care of one task.

Two people or more working on the same task? Madness! Everyone has to have their own task and be responsible for it. This way the managers can control who did what and evaluate each individual according to their individual contribution. It’s called a work-breakdown structure and corporate architecture.

The benefits of two heads

If we love this individual approach so much, why do we believe two heads are better than one?

What we are missing in the approach described above, is what Birgitta Böckeler and Nina Siessegger described in their article about pair-programming:

“While a pair of developers work on a task together, they do not only write code, they also plan and discuss their work. They clarify ideas on the way, discuss approaches and come to better solutions.”

Pair-programming means that two people sit together (in remote, they would be connected by a video conferencing tool and share the screen) and solve the same software problem together on one computer.

The short-term gains of pairing are difficult to quantify because:

  • we didn’t introduce a bug just now,
  • we made our code more modular so it will be easier to change in the future because two people, and as you keep on switching up to 8 people, have helped design this, etc.


The usage of metrics can help you to verify if pair-programming proves valuable for your team. Take a period of time say a month or three sprints before your team started pair-programming and compare it with an equal period of time doing pair-programming.

Check for such metrics as

  • velocity or number of issues per time period,
  • bugs introduced,
  • how many times you need to rework a single story

Check also for some “soft” metrics like the overall team satisfaction of the work they are doing. You can do a session of “Market of skills” and check if the team is learning new skillsets and if the knowledge about the code base is increasing.

Pair Development

The authors of the aforementioned article, describe why programming is not just about the act of coding but also about planning, organizing the work, and other tasks included in the user story lifecycle.

We should ask what “done” means? It is getting something from idea inception to “done”. We should visualize the lifecycle of a story going through all the stages. And implementation is just one of them and not necessarily the biggest one.

Start with planning the work and avoid waste.

“With four eyes on the problem this early on, catching misunderstandings or missing prerequisites can save you a lot of time later.”

1. Understand the problem — play it back to your partner to see if you both understood the same. If not, it means you need to go to the PO and clarify your doubts.
2. Come up with a solution — brainstorm potential solutions — you can do it together or each one separately and then share and compare. You’ll already have two different approaches to compare.
3. Plan your approach — once you choose the solution, plan it step by step. Is there a specific order to follow? How will you test it? Write it all down to organize the ideas and remember it later on (this is why we use JIRA and similar).
In their article “On Pair Programming”, you will find useful tips on how to approach doing the research and writing documentation.

How to start pairing?

A great way to start is by being honest to admit that you have never done it before. Maybe you are not new to pairing but have never paired in remote before. Be honest with the other person, even if you are feeling nervous about it it will help both of you to understand each other and be mindful.

Pairing etiquette

You can establish a pairing etiquette for your team. For example, if someone gets stuck, instead of just taking over you might agree to ask: “do you mind if I help you out” or “do you mind if I take control for a while?”. You might agree on a frequency of changing the roles and also the pair swapping, it might be on a daily basis or other according to your needs.

Why the rotation

One important aspect of pairing is the rotation of partners. However, a good practice is that one person should stay with a story. They are called the “anchor” of a story.

You might ask yourself why rotate if both people already know what is needed? For many reasons like holidays, sickness, getting too comfortable working together or having the need for some fresh air and perspective hence avoiding routine become “the grind”. Finally, there is also the need to break knowledge silos and spread the knowledge across the whole team. This way we increase the code ownership and get more code-review on the go.

Pairing styles

In her article, Brigitta and Nina, describe different styles of pair-programming, let’s see what they are and when to use them.

  1. Driver and Navigator
The Driver and the Navigator, photo by Toni Tan on Unsplash
The Driver and the Navigator, photo by Toni Tan on Unsplash

Use case: Developers on a similar level of seniority.

How? The Driver is programming and explaining what they are doing while the Navigator is observing and reviewing the code on the go. The Navigator also keeps an eye on larger issues, bugs, potential next steps, and obstacles. The latter should not enter into tactical details, they should take one step back and look more mid-to-long-term. The roles change frequently so the exercise keeps engaging.

2. Ping-pong

Ping-Pong, photo by Steven Skerritt on Unsplash
Ping-Pong, photo by Steven Skerritt on Unsplash

Use case: This technique embraces Test-Driven Development (TDD) and is perfect when you have a clearly defined task that can be implemented in a test-driven way. Pairing and TDD go hand in hand.

How? Ping — Developer A writes a test for this new functionality that doesn’t exist yet. And obviously, the test will fail.
Pong — Developer B writes the implementation to make it pass. They can start with the minimum necessary to make it pass. And then, once the test is green, refactor the code together. This is why it can also be represented as a red-green-refactor. This is a helpful way to put some structure around pairing, especially if you are new to it.

3. Strong-Style Pairing

Use case: Useful for knowledge transfer, can be in a set of mentor and mentee, or for onboarding a new developer.

How? Similar to Driver and Navigator although the experienced person mostly stays in the Navigator role and guides the novice.

An important aspect is that the Driver has to trust the Navigator throughout the implementation session even though they might not completely understand the solution. For effectiveness, the questions and doubts should be resolved after the session is finished. You can read more about this approach in an article by Llewellyn Falco here.

It can be a useful onboarding tool as it favors active “learning by doing” over passive “learning by watching”. But it should be used only initially, as the goal is to get out of this micro-management mode to be able to easily switch roles — evidence that knowledge transfer has worked.

Pros and cons

To summarize, there are many benefits to pairing. We talked about knowledge sharing, reflection, and more perspectives, having a code review on the go, and some focus time when you just code with your partner. It increases the code ownership and the quality of a developed solution due to introducing fewer errors and issues.

What’s more, it keeps the work-in-progress limit low and increases the overall efficiency of the Scrum Team. As a Scrum Master, I can tell you that the argument of setting some “core coding hours” gets much more convincing if we know people find it hard to pair otherwise.

Be mindful though that pair-programming is not a silver bullet, it is an Agile tool it has its challenges. It might be exhausting due to continuous social interaction, you might not like your pair or like them too much. You might get into conflicts and hate it at times. Maybe you’ll decide it is not for you.

What I can advise here is don’t judge it before you give it a try. And trying it doesn’t mean doing it once, it means doing it for a couple of Sprints, seeing how you feel, comparing the metrics, and then deciding if it is a good tool for you and your team or not.

And that’s all for today. I hope this article will inspire you to explore more about pair-programming and encourage you to try it at work!


Created by

Maria Chec

I make sense of chaos. Drive focus and coordination of numerous teams. And I am a content creator, check out my YouTube channel:







Related Articles