Convince the skeptics
Let’s be honest, working alone can only get you so far. Collaborative programming is the future, and by implementing it, you'll be unlocking your team's full potential. So let's dive into some practical tips to make pair and mob programming a game-changer for your team.
Many business people believe that pair and mob programming are a waste of time. They think two developers working together on the same task is less efficient than each working on separate tasks. However, this is a common misconception.
The first thing is that if all developers work on a different task, at some point they have to merge their code to master: while the Pull Request/Peer Review approach is great for Open Source, things are different when it comes to software development team work.
Working together on software brings better results if done synchronously: PRs are a waiting time, causing the developer waiting for review often to fall into mistakes like starting a new task, which will only lead to more issues like too much work in progress and context switching.
In fact, context switching has a terrible impact on productivity.
To demonstrate this, try an exercise with all the skeptical people you meet. Ask them to write all the letters they can in 5 seconds (A, B, C, …), then all the even numbers they can in 5 seconds (2, 4, 6, …). Finally, ask them to alternate between letters and even numbers for 10 seconds (A, 2, B, 4, …).
You'll see that despite the same amount of time for the same amount of work, the third task is less productive due to context switching.
I can hear you all, remote work lovers: I know, when working remotely async work seems very attractive. It is, and should be, the default choice for a lot of communications and other kind of works, but not for software development. The best setup, IMHO, is having remote teams organized by timezone in order to be able to work in pair/mob. Of course, async work for software development offers more freedom to people and allow to hire people from all over the world, but it’s a great compromise for productivity: as always, it’s important to be aware of the compromise we are taking!
Match the pairs
Pair programming is a great way to start since it’s easier to set up and find tasks to start working on in pairs.
Begin by pairing up developers who are more enthusiastic about trying it out. Once the entire team is onboard, establish a rule for choosing pairs.
Some strategies include assigning stories until half the team is full, creating a rotation like a speed dating event, or randomly extracting people each time. Each strategy has its pros and cons, but the goal is to avoid fixed pairs and encourage communication among all team members.
If you feel the need to encourage pairing, a good approach is typically to introduce this kind of practice during learning moments: organize team-wide learning sessions where you can focus on pair programming or use it as a technique to exercise a new language or methodology.
Another way to encourage pair programming for working on production code is to allow merging the code without a Pull Request: you can totally remove it (use standups + share commits for sharing knowledge about implementation) or add an expiry rule (2 hours to review it or it is automatically mergeable).
NB: removing the Pull Request must be done in a safe way! Ensure you trust enough your team, automated pipeline and/or test environment before introducing this rule.
Organize for the mob
If you're ready to take things to the next level with mob programming, you'll need a setup that makes it comfortable for everyone.
In the office, create a room with a big screen or projector, where everyone can connect their personal computers and keyboards without disturbing others. Use a timer to rotate the driver position and allow for breaks when needed. If someone needs to work on a quick task or simply take a small break, set up a small location nearby where they can isolate themself for a while (but make sure it's close enough to ask for help if necessary!).
If you're working remotely, use tools like Discord or Slack to share online rooms organized by topic. Encourage everyone to keep their cameras on for engagement, but be empathetic if someone needs to turn theirs off. Use a timer to keep everyone on schedule and take more frequent breaks due to the added fatigue of working on camera. For brainstorming or discussions, use a tool like Miro to visualize ideas.
Finally, regardless of your setup, apply the single-piece flow approach, which means only one thing is in progress at a time. This is a perfect match for mob programming, and it's important to commit often so that every driver can share their changes with others.
Conclusion
Pair and mob programming are powerful tools that can greatly benefit your team. By using these setup tips, you can start collaborating like a pro and see increased productivity and engagement. Give it a try and never go back to working alone again!
Go Deeper
Here are some resources you can check if you want to go deeper and learn more about Pair and Mob Programming.
Books
- 29 Guidelines for successful Pair Programming - a small list of practical tips for good Pair Programming, by Oozie Ligus
- Software Teaming: A Whole Team Approach - The primary book about Mob Programming, by Woody Zuill
Online
- On Pair Programming - by Martin Fowler
- Pair Programming: What, Why, and How - by CodeMentor