I've introduced Mob Reviewing as an approach in my team in order to tackle two problems. One being that pull request reviews were a bottleneck in our throughput as a team. And two, I wanted to standardise how we as a team approached reviews from a technical and social level. Getting many hands on deck to review pull requests together seemed to me a natural marriage of problem and solution. Two birds, one mob thrown stone.

Mob Reviewing is a take on Mob Programming, but applied to reviewing pull requests instead. Most of the same rules apply; the entire team gather around one screen (in person, or remote) and collaborate to solve the problems at hand. However, with some slight differences..

A Mob Review session can be setup as follows:

• There are three roles*: typist, reviewer and PR owner.
• The typist shares their screen and types comments on behalf of the reviewers.
• The reviewer (this should be everyone who isn't the typist, or PR owner) will speak their thoughts and opinions over the code presented.
• The PR owner can provide context and answer questions over the intent in the approach taken. Otherwise they also fill into the role of reviewer.
• At a set amount of time (say every 8, 10, or 15 minutes) the typist should swap to the next reviewer.
  • Set aside an hour for the session, after which reviewers may leave if they'd like.
  • However, allow the session to go on for as long as the team feels its productive.

At the beginning of a session the initial typist should share their screen, showing the ticket which is going to be reviewed. This is the opportunity for the team to raise any clarifying questions before beginning, along with gaining context for what they will be reviewing. Once this has been completed, the session can begin. Start the timer, then

• Have the typist open the pull request and share the first file.
• Let the typist slowly go through all the changes made in the file and allow for any of the reviewers to ask questions, or express an opinion.
• When a reviewer is ready, they should present their opinion and invite a discussion, where the team is brought to a consensus of what the appropriate course of action is:
  • Leaving a comment (where the reviewers tell the typist what the comment should contain), or
  • agreeing that no action needs to be taken.
• When the team has agreed there are no more comments required on a file, move to the next.
• When the timer runs down to 0, wait until the team has finished with the file at hand, then move to the next reviewer.

What we found as a team while doing Mob Review sessions:

• We engaged in knowledge sharing frequently.
• An increase in productive problem solving discussions.
• During sessions and outside of them.
• Reviews have become more standardised and consistent throughout all members of the team.
• Confidence in the psychological safety of each other.
• Our preference in session length is between an hour and a half, to two hours and a half.

The benefits haven't been just qualitative but quantitative too. As a result of our ongoing Mob Reviewing sessions, reviews have occured more often and sooner, along with our overall development output (or velocity) increasing.

As an added bonus, the sessions have been fun. Because we're face to face, having discussions, and working as a team. We felt like a team, which has brought us all closer together. It's helped us form a team culture where we tackle problems as a team, rather than as individuals, and we enjoy the journey.

Since we've gained so many positives out of reviewing code together as a mob, it'll be a practise that we'll keep around.