A Practical Guide To Getting Started with Pair and Mob Programming
“How can we be productive if we separate people who should be working together?” — Woody Zuill
You may have heard that coding together sets up a platform for continuous learning. That it breaks down knowledge silos and accelerates the feedback loop, enabling teams to deliver higher quality software, faster.
You may also have tried coding together only to discover that the stated benefits did not materialise. What could have gone wrong?
Consider a team of sportsmen. It is highly unlikely that they would play well just by being on the field together. Or a group of surgeons. That they would operate effectively just by being in the operating theatre together. In the same way, coding together doesn’t work just by seating two or more individuals together.
We must define roles and processes for the practice to be effective. Or at the very least, to help us get started.
There are several formations for coding together that we can consider. One that works well in most situations, and extends seamlessly into mob programming, is “Strong-Style” pair programming. The rule of this formation is:
“For an idea to go from your head into the computer, it must go through someone else’s hands” — Llewellyn Falco
Roles
There are two key roles in this form of coding together:
- The driver, and
- One or more navigators
A person may additionally be nominated to facilitate the session.
Driver
The driver is the person at the keyboard. They take high-level instruction from the navigator and translate it into code. The driver is focused on solving the specific problem at hand.
“For best results, you must believe that the solution to the problem you’re working on lies buried in another person’s subconscious mind.” —Oozie Ligus, 29 Guidelines for Successful Pair Programming
The driver should not implement a change unless the intent is expressed by the navigator. If the driver has an idea, they should wait their turn to navigate or request for the navigator to switch roles.
If the driver is new to the team or technology, they may stay on in this role for an extended period of time. This is to allow the driver to familiarise themselves before taking on the role of navigator.
Navigator
The navigator keeps a holistic view of the problem statement and guides the driver from one problem to the next. Navigators generally provide a high level of instruction but may drop to lower levels, such as when the driver is not fluent with the development environment at hand.
When the “Strong-Style” formation is extended to mob programming, there is more than one navigator. It can be overwhelming for the driver to receive instructions from multiple navigators, therefore one of the navigators is nominated as the primary navigator. The primary navigator discusses ideas with other navigators, before providing the final instruction to the driver.
Facilitator
A facilitator may be nominated in each session until the team is accustomed to the rules and roles of coding together. A facilitator keeps time, manages rotation, ensures breaks are taken and that the driver/navigators stick to their respective roles. Facilitators may also conduct a short retrospective at the end of each session to gather feedback and discuss learnings.
Rotation
The driver and navigator switch roles at a predefined time interval, e.g. every 5 or 10 minutes. Switching roles at short intervals may seem difficult at first, but the constraint forces participants to break down work into smaller increments of working software.
With experience, rotation can occur naturally.
When rotating while mob programming, the driver makes a good candidate for taking on the navigator role. The driving seat allows team members to get into context, and then continue on from where the previous navigator left off.
Maintain a TODO list
When kicking off a pair or mob programming session, it is useful to spend a few minutes creating a TODO list together. This is to allow all navigators, even those that are new to the team, to have a bearing on where the session is headed, and how to get there. The TODO list may change over the course of a session as new knowledge is discovered.
Practice, practice, practice!
It can be overwhelming to try out a new skill in a production environment. Consider setting up a few practice sessions with the team to learn how to code together before moving on to real-world problems. Try coding together on coding katas listed here: kata-log.rocks.
Here are a few questions that often come up when getting started:
Can coding-together cause burnout?
Pair programming is more susceptible to burnout. The activity can be exhausting because both partners keep each other focused and in a state of flow. It is important to take frequent breaks to recharge. There can also be stress associated with being available for one another, as whenever either partner is not around, work stops.
Mob programming helps mitigate the risk of burnout. It ensures work goes on even when a team member is unavailable. Individuals can take a break or leave without having to worry about impeding work.
What is the ideal size of a mob?
In my experience, it is 4 to 6 individuals. Team members can take vacations and breaks, join in late or drop off early, without impeding work.
Should we code together on all tasks?
By default, yes. We might assume that coding together on trivial tasks is an inefficient use of time. However, if it is painful to work together on certain tasks, it may indicate that the process itself has room for improvement. And process improvement is usually not a trivial task.
“Where an individual tolerates wasteful practices, a mob amplifies and addresses those.” — Maaret Pyhäjärvi, Ensemble Programming Guidebook
An exception is R&D, where you may choose to try out various solutions independently. These are known as Spike Solutions. Code produced from the experiments is subsequently discarded, and the team proceeds to co-create production code.
We are working remotely. Can we still code together?
Of course! Try setting up a “Virtual Room” — a static meeting link to make it easier for team members to find each other.
And that’s it, you are well on your way to co-creating code! This guide is by no means definitive, it is just to help get started. Once you learn to follow the rules, adapt and keep improving.
“Agile software development is an ongoing process of learning and improvement. Never stop practicing, experimenting, and evolving.”— James Shore, The Art of Agile Development
To learn more…
- (YouTube) Mob Programming: A Whole Team Approach by Woody Zuill
- (Blog) Llewellyn’s strong-style pairing by Llewellyn Falco
- (Book) Ensemble Programming Guidebook by Maaret Pyhäjärvi
