BLOG
Have you ever wondered which came first: the chicken or the egg? The same question could be asked of psychological safety and group or pair programming. Indeed, these concepts feed off each other to improve the work of software development teams. In this blog post, you'll learn more about peer programming and mob programming, and the positive impact they have on psychological safety and team performance.
Some Definitions
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 a great deal of 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 along the way, discuss approaches and come up with better solutions.
Mob programming
Mob programming is an approach to software development in which the whole team works on the same thing, at the same time, in the same space and on the same computer. This approach extends the concept of pair programming to the whole team, who collaborate continuously on a single computer to deliver a single piece of work at a time.
Psychological safety
Organizational behavior 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. Peer and mob programming appealed to me because they are methodologies that address real problems in software development. They allow us to avoid certain common frictions by changing the way we work. Two common examples come to mind:
- I have a merge request pending and I need to follow up with my colleagues for approvals.
- 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 the world of software development, but the focus is often on customers and users, whereas developers can benefit from them too. By having someone next to us to ask questions, we can discuss and justify decisions with a peer without having to start 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.
Travailler en binôme permet de donner une rétroaction en temps réel
How do you switch to peer or mob programming?
Since you have to start somewhere, it's important to realize that there will be a learning curve involved in implementing this new way of working. The important thing is to try it out and accept that it won't be perfect the first time. Peer 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 peer programming.
What's more, it's time to dispel the myth that two developers working on the same computer is 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 peer 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)
Peer programming optimizes work sequences: a story goes from to-do to done very quickly, without blockers. The team has less work in progress (WIP), but delivers value more quickly. At Nexapp, we believe that until something is delivered, there is no value. 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 peer 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 peer programming and psychological safety?
Vulnerability is at the root of psychological safety. Taking a risk around your team members may seem straightforward, but 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 in order 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.
Peer 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 able to be, the better he'll work in peer 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 peer and mob programming is vulnerability. Teammates must accept that they each have their own strengths and weaknesses, and that not everyone contributes in the same way. That's what makes for a high-performance multidisciplinary team: when everyone brings their strengths to the table and makes up for their weaknesses 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 important ingredient is kindness. Set a pace that suits the team. Sometimes you have to slow down to go faster, and peer programming is a good example of this. 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 eventually go faster.
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 to slow 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.
Mob programming enables development teams to make better decisions.
Feedback and psychological safety
With pair or mob programming, developers get used to receiving positive, negative and constructive feedback, with the aim of becoming even better at what they do. It's also easier to assimilate feedback when it's 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 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 when this process is carried out asynchronously, there's no such exchange.
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 greatly to productivity!
Should we work in pairs every day?
For all sorts of reasons, it's not possible to do pair programming 100% of the time. 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 peer 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!