Part 11: Unleash Your Scrum with Multi-Skilled Professionals — Pair Work to Enable Social Ability
In our last article, we uncovered the power of Social Ability to transform a team’s mindset from “my problem” to “our problem.” In this article, let’s discover how to turn this “our problem” mindset into everyday action. Pairwork, a time-tested practice, provides a foundation for multi-skilling, knowledge sharing, and collective problem-solving. This article will explore how pairwork ignites skill development, cultivates a deep understanding of the product, improves code quality, and builds a stronger, multi-skilled team.
If you’re joining me for the first time, I recommend reading the previous parts for context:
Unleash Your Scrum with Multi-Skilled Professionals — Series Outline
Chapter 10
10.6. Creating Social Ability
Try … Pair Work
A Short History
Pair programming has been around for a while. It’s a practice that has its roots in the early days of software development, when programming felt more like a new and exciting craft.
We can trace the idea of pair programming back to Fred Brooks, who mentioned it in his classic 1975 book “The Mythical Man-Month.” Brooks tells a story of working side-by-side with a colleague between 1953 and 1956 and how their teamwork produced code that was remarkably bug-free from the start.
Fast forward to the early 1980s, and we find Larry Constantine observing pairs of programmers working together at Whitesmiths Ltd. He nicknamed these pairs “Dynamic Duos” because they were cranking out solutions quickly, and their code was impressively clean. Constantine realized that pairing wasn’t just about doubling up on work; it was a way to boost efficiency and create better-quality code.
In 1995, James Coplien put a formal name to the practice: “pair programming.” He explained how this tandem approach allows designers to work together, solve problems effectively, and benefit from constant communication and feedback. This gave pair programming a clear identity and highlighted its value in problem-solving and improving code quality.
As the 1990s came to a close, pair programming really gained popularity with the rise of Extreme Programming (XP). Kent Beck included it as a core practice in his 1999 book on XP, where he strongly supported its use.
How Does It Work?
In pair programming, team members work concurrently on one or more product backlog items. A pair works on a task together at one machine (or screen in a remote setting).
The practice assigns specific roles and responsibilities to each pair member. At any point, each person assumes one of the two roles:
- The Driver is responsible for the actual coding.
- The Navigator is responsible for reviewing the driver’s work and providing a strategic perspective on the code.
The pair can use different strategies to switch positions:
Chess clock: The pair assigns a period for performing each role using a chess clock. The pair switches roles when the clock rings, or a natural breaking point occurs.
Ping Pong: Consider the pair comprising Developer A and Developer B. Developer A writes a new test and sees it fail, then Developer B implements the code needed to pass the test. They switch roles, and Developer B writes the next test, and so on.
Strong-Style Pairing: In this approach, the Navigator, usually more experienced, verbalizes the idea to the Driver, who is often a novice. It’s as if the idea navigates from the expert’s mind through the novice’s cognition, flowing through their fingers onto the code. This method allows the novice to “learn by doing,” which is more engaging than merely watching.
Continuous 8-hour pairing can be mentally exhausting. About 5–6 hours of pairing a day can be a sweet spot, with the rest of the time allocated for other types of work. Pairs rotate frequently, working with new partners every few hours and switching at natural breaks during development.
Since pair programming requires close communication and collaboration, it may take some acclimatization to benefit from such sessions fully. Running brief feedback sessions after each pairing, using the previously suggested feedback framework, can help refine the experience, making it more enjoyable and productive.
How Does It Help Multi-Skilling?
At its core, pairing is about discovery and cross-skilling across various realms.
Begin with the simple, tangible moments. Envision this: As you navigate through a class with five methods, you decide to shuffle a private method from top to bottom. The typical cut, scroll, and paste routine would take a good 10 seconds. But your teammate gets it done with a slick keyboard shortcut in the blink of an eye. It’s a small revelation, but now that magic shortcut is part of your toolkit, too.
As you work together in pairs, you start to understand your product better — from the business goals and user needs right down to the details of the code. You learn why a feature was added, the problems it solves, how it was built, and even the potential technical issues that might exist. These questions come up naturally as you and your teammate talk through your work. In contrast to working alone and just focusing on getting things done, pairing encourages deeper conversations about the “why” and “how.” Anton Bevzyuk, Head of Engineering at Mindbox, shares a story about how his team spent a lot of time refining a task during backlog refinement, but still had different understandings of it when they started coding. It felt like they were working from different scripts. But the beauty of pairing showed itself — they were able to quickly spot the differences in their understanding and go back to the business team for clarification. Working alone, that misunderstanding might have gone unnoticed, but together, they caught it early.
This team spirit extends to learning together as well. Anton shares another story about how his team, primarily experienced in backend work, took on a new challenge. The website team was overwhelmed, and a critical new feature was at the top of the product backlog. Even though they didn’t have much frontend experience, they decided to step up and help. Luckily, a developer from the web team joined them as a “traveler” for a sprint to get them started. That teamwork didn’t end after the sprint — the web developer continued helping, reviewing code, and answering questions as the team learned the ropes. After a few weeks, the team became skilled enough to handle most medium-complexity website tasks on their own. They weren’t React and Redux experts yet, but they could manage about 80% of the typical work. And for the remaining complex tasks, they knew where to go for help. This effort didn’t just get a critical feature done; it was a hands-on learning experience for the team, expanding their skills on a real-world project through learning by doing.
A Wealth Beyond Skills
Pair programming expands your skills and opens the door to many other benefits that are important for creating successful products. Let’s explore some of the advantages found in a study called “The Costs and Benefits of Pair Programming” by Alistair Cockburn:
Product Focus: Without being limited to narrow specializations, the team can focus its energy on the most important feature at any given time instead of everyone working on their own thing.
Better Product Solutions: The process of turning an early idea into a finished feature is a team effort. It’s about understanding what users need, keeping that goal in mind, having in-depth discussions, and working through different perspectives to find the best solution.
Speed: Pairs tend to solve problems faster, which often makes up for the seemingly ‘slower’ coding process. If one person gets stuck, the other can jump in and keep things moving. A big reason for this speedup is that there’s less need for separate code reviews later on — a process that’s helpful, but can cause delays. Pairing catches potential issues early. Since pairs switch roles and partners often, many people see the code from different perspectives. This aligns well with agile practices like Continuous Integration and Test-Driven Development because you get feedback as you go. These ongoing conversations while coding reduce the need for formal code reviews later.
Code Quality: Pairs often write less code, sometimes up to 80% less, without sacrificing features or how well the code works. This means they find simpler, more elegant solutions for problems. They also make fewer mistakes — the defect rate can drop by up to 15%! Code written during pairing is also easier to read and understand, which makes it easier to maintain. During automated testing, this code can score up to 20% higher. Since pairs share the work, everyone feels ownership over the code — it’s not just one person’s responsibility any more.
Developer Confidence and Satisfaction: Cockburn’s study found that paired developers had a confidence level of 6.8 (out of 10), almost twice the score of solo developers at 3.8. They were also about 1.5 times more satisfied with the final product. Anton’s experience shows similar results—about 90% of those who try pair programming find it rewarding.
True Teamwork: Pair programming is more than just writing code together; it’s a way to build strong teams. Imagine this — before you even write a line of code, you have to explain your idea to your partner. To make sure they understand, you have to use clear language and a simple explanation of your solution. Your partner might say, “Hmm, that doesn’t seem quite right. What if we try this way instead?” Now, you’re working together, discussing different options, and even trying out a few variations in the code to see what works best. This helps you practice communicating clearly, explaining your ideas, listening to different viewpoints, and building strong arguments. Instead of getting stuck in endless theoretical discussions, you’re actively testing solutions in the code itself. Pairing changes how you discuss problems and helps the team work together to find solutions.
200% Accountability: When you pair, you and your partner help each other stay focused and committed to the team’s work and the goal. Everything is done in the open, so it’s easy for everyone to see what’s going on.
Venturing into Pairing
Trying pair programming requires some curiosity and a bit of planning. Reading books like Kent Beck’s “Extreme Programming Explained” or “Agile Technical Practices Distilled” can give you a good foundation.
Pair programming might initially seem a bit mysterious or even scary, like those teenage years. You might have lots of ideas but not much real-world experience yet.
The idea is simple — just try it! Your project won’t fall apart if you spend a sprint or two exploring pair programming. Any hesitation you feel at first will be replaced by the benefits of working together.
The key is to start slowly and build a good teamwork rhythm over time. A good first step is to pick a task, maybe a small one to begin with, and tackle it together. Programmers often work in pairs on tough problems anyway, so this isn’t so different.
It’s normal for old habits to be hard to break. Having some clear guidelines on how you’ll work as pairs will provide a helpful structure. It’s about finding a good balance between working alone and working as a team, so the experience is rewarding for everyone.
You could start by setting aside some dedicated time for pair programming each day — maybe from 10 to 12 AM. Leave the rest of the day flexible to start with.
If you want to dive deeper, try committing to full-time pair programming for a couple of sprints. This helps you really learn how it works and see the benefits. But remember to be organized — use a timer to switch roles and make sure everyone pairs with different people.
Taking the first step toward pair programming isn’t as scary as it seems. Just jump in, start working together, and learn how to solve problems as a pair. The more you practice, the less intimidating it will feel.
This exploration of pair programming shows how it transforms the “my problem” mindset into a shared sense of “our problem.” This change enables the power of collaboration. Through continuous communication, shared code ownership, and faster identification of issues, pair programming cultivates a deep understanding of the product, fosters high-quality code, and builds a strong team dynamic. This lays a rock-solid foundation for tackling those complex problems where no single person has all the answers.
Now, we can build on this foundation to enhance Social Ability further. In the next couple of articles, we’ll delve into the power of mob programming and swarming, exploring how these dynamic techniques amplify collaboration, accelerate learning, and help teams tackle their toughest challenges head-on.
Continue exploring the nuances of multi-skilling in transforming our Scrum practices and elevating our teams to new heights of agility in the next part of the series:
References
- Cesário Oliveira Ramos, Ilia Pavlichenko. Creating Agile Organizations. A Systemic Approach (Addison-Wesley, 2023)
- Pedro Moreira Santos, Marco Consolaro and Alessandro Di Gioia. Agile Technical Practices Distilled. A Journey Toward Mastering Software Design (Packt Publishing, 2019)
- Alistair Cockburn, Laurie Williams. The Costs and Benefits of Pair Programming (ResearchGate, 2000)
- Kent Beck, Cynthia Andres. Extreme Programming Explained: Embrace Change (Addison Wesley Professional, 2004)
- Falco L. Llewellyn’s strong-style pairing (2014)
- RooksbyJ. et al. The theory and practice of randori coding dojos (2014)
