Pair Work in Software Development Teams

Why and how have we implemented pair working practices in our team at Unity Helsinki

Written by Matti Frimodig, Senior Software Developer @ Unity

In this article I’m going to introduce the pair working style we here at the Unity Wallet software development team are using. The concept of developers working in pairs is in no way unique to our team and is in fact utilized by many other teams in Unity Technologies and indeed the entire software industry, but for this article the focus is on our team’s particular methods and reasoning.

Why work in pairs

When taking any tools or methodologies into use the first task is to always identify the problem we are trying to fix, as otherwise it will be impossible to determine success or failure.

The three problems we are using pair work to tackle are knowledge silos, slow feedback loop, and lack of support.

• Knowledge silos are a common problem with developers as it is easy to end up in a situation where the bulk of the work in a project or component ends up being done by the same person. A good indicator of this problem is that specific tasks are getting delayed as it “makes sense” to wait for a key person to be available rather than have someone else look into it.
• Slow feedback loop in this case means that a developer will work on a task or feature and only submit for peer review when its ready. Sometimes at that point we find that the implementation doesn’t actually solve the issue due to some misunderstanding, or possibly that there would have been a faster and simpler solution available.
• By lack of support we mean situations where a developer will repeatedly attempt to solve problems on their own even when knowledge that would help already exists in the team. Usually teams define an escalation path, but asking for help can be daunting. And even if a developer does ask for help it usually involves waiting time as other people on the team are working on their own tasks, meaning that jumping in to help someone could mean re-prioritizing work and the additional hassle of context switching.

The next step is to see how the proposed solution fits the problem description and look at any other concerns or benefits related to it. Our basic approach is that a pair works on a story together. Exactly how they do that is left to the pair, but most pairs tend to use a similar method (see the next section).

Benefits of working in pairs:

• Increased knowledge sharing
• No single person silos
• Get faster feedback without formal reviews
• Planning together means ideas are evaluated faster and misunderstandings are less likely
• Pairs can ask each other for help easier since they have the same context and share the priority of getting their story finished
• Pairs are less likely to both be unavailable, for whatever reason, halting work on a story

As you can see it looks like a pretty close match to the problems outlined earlier.

Typical pair working flow in the team

So how exactly do we work as pairs? As I mentioned earlier the exact details are left to the pairs themselves, but in our team most choose to follow this general structure. It is worth mentioning that we follow a sort of loose Scrumban with a weekly cadence and our process might not be directly compatible with other methodologies, but much of it could still apply.

• Product Manager introduces a new Product Requirement Document and works together with the whole team to create user stories
• Pair that needs a new task to work on takes a story from the prioritized backlog and begin technical planning
• Story is split in to subtasks by the pair
• Any issues with the story are clarified with the Product Manager
• Pair provides an estimate for the story
• Pair works on the subtasks they defined. This can be pair coding, working on individual areas (front/backend), doing the tickets separately in priority order, or any combination of the above
• Pair finishes the story and picks the next one from the top of the backlog

Choosing and changing pairs

Working in pairs clearly has its benefits, but we get even more mileage from it by changing the pairs regularly. There are several new benefits that come into play

• Working with different people exposes you to knew ideas and you can learn new skills from your pair
• Onboarding to new part of the project is smoother when you pair with someone who has already been working with it
• With rotation people on the team will have an experience of working closely with multiple different team members, which helps improve overall communication in the team

While there is a case for totally random pair assignment to ensure that eventually everyone has worked with everyone we do however have some guidelines on what we are looking for when deciding which developers will pair up.

• Complementary strengths, e.g. fast developer paired with meticulous developer
• Different levels of experience to provide a mentoring effect and to ensure that the most senior team members are spread out on different stories

Finally on the topic of changing pairs we found that pairs should stay together for a reasonable time as switching pairs can disrupt work for a while. Finding an optimal time to switch can be tricky as pairs will not be working on a set cadence and switching while a pair is in the middle of a story leads to disruption.

The team needs to enforce pair rotation because of the points above, and due to people being creatures of habit, switching pairs won’t happen often unless enforced. Many of the benefits of the system require the changes to actually happen.

Closing thoughts

We found that the benefits of developers working in pairs outweigh the overhead caused by it, and encourage you to try out something similar in your organization. Alternatively, come and find your future pairs at Unity Helsinki.

If you want to read more about how we work in the Unity Wallet team you might be interested in my previous article on Kotlin, our team’s primary programming language.