Pair And Mob Programming For Psychological Safety

Before getting to the heart of the matter, here are a few definitions just to make sure that we are on the same page:

Pair programming

Pair programming means that two people write code together on a computer. It's a highly collaborative way of working that involves much communication. When a pair of developers work together on a task, they don't just write code; they also plan and discuss their work. They clarify their ideas, discuss approaches and develop better solutions.

Mob programming

Mob programming is an approach to software development in which the whole team works on the same thing simultaneously, in the same space and on the same computer. This approach extends the concept of pair programming for the entire team, who collaborate continuously on a single computer to simultaneously deliver a single piece of work.

Psychological safety

Organizational behaviour specialist Amy Edmondson of Harvard University was the first to introduce the concept of psychological safety, which she defined as "the belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes, and the team is safe for interpersonal risk-taking.". Google researchers identified that, of the five key dynamics of effective teams, psychological safety was by far the most important. They found that team members with greater psychological safety were more likely to harness the power of their teammates' diverse ideas and were rated twice as effective by managers.

Why pair or mob programming?

Being very involved in the software development community, I like to try new concepts from the industry and learn about their benefits. Pair and mob programming appealed to me because they are methodologies that address real problems in software development. They allow us to avoid inevitable common frictions by changing how we work. Two common examples come to mind:

1. I have a merge request pending, and I need to follow up with my colleagues for approval.

2. I don't like receiving comments on finished work for details.

The problem with these situations is that all the feedback comes afterwards. It's easy to put yourself in the developers' shoes and understand that they don't want to touch up a completed task or wait for approval to move forward. The solution: faster feedback to eliminate friction. And the best way to give feedback quickly is to do it while the code is being written!

Rapid feedback loops are nothing new in software development, but the focus is often on customers and users, whereas developers can benefit from them, too. Having someone next to us to ask questions allows us to discuss and justify decisions with a pair without starting a task from scratch. Code review in real time! This way of working also allows comments to have more impact and developers to realign themselves without wasting time.

How do you switch to pair or mob programming?

Since you have to start somewhere, it's essential to realize that a learning curve will be involved in implementing this new way of working. It is important to try and accept that it won't be perfect the first time. Pair and mob programming are worthwhile experiments if you give yourself time to iterate and refine your way of doing things. Ideally, you should start with someone who has already done it to get a good first experience and learn what vulnerability means in pair programming.

What's more, it's time to dispel the myth that two developers working on the same computer are not productive. If we consider all the asynchronous interventions when each is working on a task, developers can work a similar number of hours even if they don't do it simultaneously. At least, with pair and mob programming, the result is maximized, even if there are slightly fewer "checked off" tasks at the end of the sprint.

Focus on outcome (results) rather than output (completed tasks)

Pair programming optimizes work sequences: a story goes from to-do to done quickly, without blockers. The team has less work in progress (WIP) but delivers value more quickly. At Nexapp, we believe there is no value until something is delivered. So, a high WIP isn't necessarily a sign of productivity if everyone's working on tasks that stall in review or QA. It's a good idea to think about it!

Also, stories delivered using pair or mob programming are of the highest quality, since they have benefited from the software engineering of several developers who have agreed on the requirements, challenged each other and discussed them at length. The probability of delivering an excellent result is much greater than when working alone.

What is the link between pair programming and psychological safety?

Vulnerability is at the root of psychological safety. While taking a risk around your team members may seem straightforward, asking a basic question like "What is the purpose of this project?" can give the impression that you're not up to speed with your files. It may then seem easier to keep moving without asking for clarification to avoid being perceived as ignorant.

To work on a shared screen with a colleague, you have to know how to make yourself vulnerable, because you can't hide.

Pair programming and psychological safety are part of a never-ending loop that leads developers to work more humanly and effectively. The more vulnerable a developer is, the better he'll work in pair programming or in a group, and the more vulnerable he'll be able to make himself ... and so on!

In addition, one of the success factors of pair and mob programming is vulnerability. Teammates must accept their strengths and weaknesses and that not everyone contributes similarly. That's what makes for a high-performance multidisciplinary team: when everyone brings their strengths and makes up for their shortcomings with the team's expertise.

How can vulnerability be fostered and maintained within the team?

First, it takes a person recognized for his or her expertise, ideally a leader, who agrees to reveal that he or she doesn't know everything. At that point, other team members who see someone they admire becoming vulnerable will be inclined to do the same. Vulnerability can become contagious and spread quickly in a good, non-judgmental corporate culture.

Another vital ingredient is kindness. Set a pace that suits the team. Sometimes, you have to slow down to go faster; pair programming is an excellent example. I advise development teams to take the time to ensure that everyone understands how and why we work in a certain way because developers who aren't up to speed, on the one hand, slow down the team (and will continue to do so if we don't take the time to explain methodologies to them), and on the other hand have the potential to become the best players to go faster eventually.

It's important to avoid short-term thinking and put the team's long-term well-being first. Take a field hockey team: if two out of five players can't skate, the team will always be outnumbered. Star players must learn to put their personal productivity aside and play as a team.

Finally, to foster vulnerability, the best leaders will be those who lead by example, accept slowing down, include all talents, and show themselves to be vulnerable. Leaders who adopt a coaching vision can help developers find their place and gain confidence in their abilities.

Feedback and psychological safety

With pair or mob programming, developers get used to receiving positive, negative and constructive feedback to become even better at what they do. It's also easier to assimilate input when given during the task rather than afterwards.

Indeed, receiving feedback after completing a task can give the developer the impression of taking an exam: you hand in a piece of work, move on to something else, then receive a grade later when you've already started to forget the subject.

By receiving feedback during development, we can explain ourselves, question ourselves, and ask ourselves why we work in a certain way. The developer can then understand why he or she needs to make changes and do so in real time rather than sometimes starting over from scratch.

It's also possible that the discussion will lead to a new solution, even better than the one everyone came up with in the first place. Discussion is very important, and there's no such exchange when this process is carried out asynchronously.

Other benefits of pair and mob programming

• Share ideas more often (and get in touch with new ideas!)
• Learn to compromise as a team
• Agree on good working practices
• Share knowledge within the team
• Eliminate the fear of losing a player (and not knowing how to maintain your code!)
• Share the pressure of group deadlines
• Encourage collaboration between team members
• Establish a safety net for the team
• Improve proximity and benevolence between team members
• Reflect more often on the reasons behind our actions
• Verbalize the automatisms developed with experience

And all these non-tangible benefits contribute significantly to productivity!

Should we work in pairs every day?

It's impossible to do pair programming 100% of the time for all sorts of reasons. For example, some people need to be alone from time to time for their mental health, or a particular task is easy to split, and you don't feel the need to work on it in a group. However, I recommend pair programming whenever there's a lack of clarity about what's required, a need for team discussion, or hesitation about which path to take.

Whether your team works solo, in pairs or in groups, the trend is towards collaboration in software development. Combined with a psychologically safe environment, collaboration is just the beginning of better software delivery performance.

Have you tried pair or mob programming? What are you doing to promote psychological safety in your team? I'd love to hear from you and discuss it with you!