At FARFETCH, teams are encouraged to try new development methodologies so that they can deliver even better results while also improving productivity. As a fairly new team, we have continuously been looking for different methodologies that best fit our needs, such as avoiding knowledge silos or a slow-paced reviewing process. Although not every approach that we have tried has worked, the ones that did are now part of our daily development workflow and play a key role in the outcome of the tasks that we deliver.

A year ago, our team was first introduced to Mob Programming, and we have been using it since then. The concept that was once hard to fathom is now the go-to approach when dealing with most of our sprint tasks. Although being able to use Mob Programming daily has come with many different types of challenges, the results have been surprisingly good.

What’s Mob Programming?

When using Mob Programming, instead of having each team element working on its own task, the whole team gathers together to tackle the same task. It includes using a single workstation and only one person typing - the Driver - while the remaining people are describing the path that should be taken.

It’s a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. - Woody Zuill (2014)

Mob Programming is somewhat similar to Pair Programming. While the latter consists of having two team members sharing the same workstation, Mob Programming goes a bit further and implies having the entire team focused on a single task. Even though Pair Programming is a great tool to share knowledge, improve communication and even bring better outcomes (as a consequence of having multiple people thinking about the same problem), it confines these advantages to only two elements on a team. On the other hand, Mob Programming can amplify these benefits to the whole team.

Yet, having an entire team working on the same problem brings its own challenges. It’s imperative that the team establishes a set of well-defined procedures and rules. Furthermore, Mob Programming may not be suitable for all kinds of tasks or teams. Depending on the task the team is tackling, it should first be established whether Mob, Pair or Solo Programming is the appropriate methodology. None of the three is suitable for all situations. It’s up to the teams to give them a try and figure out when to use them.

How does it work?

A typical Mob Programming setup consists of moving the team to an isolated space (e.g. a meeting room) and bringing one computer that should be connected to either a large monitor or a projector. Having a whiteboard to write down possible solutions and describe the next steps is great to empower collaborative brainstorming. Seats and tables for everyone is a must, as everyone should be comfortable during the session, this is particularly relevant as these sessions tend to be time-consuming. Since the beginning of the Covid-19 pandemic, we have adapted our ways of working to facilitate Remote Mob Programming sessions - but more to come on that later.

Environment & Setup

Two key roles must be considered when using Mob Programming: the Driver and the Navigator. The Driver is the person at the keyboard, responsible for moving the codebase forward. The Navigator understands what the group has decided to aim for and provides instructions to the Driver. The Navigator shouldn’t dictate the actual code that the Driver has to write down, only the expected solution. Sometimes, the Navigator role may not be needed. It is up to the Driver to opt-in or out. Nonetheless, when there’s no Navigator, the Driver may get lost by having multiple people explaining what to do. These roles should rotate between all team members at regular intervals (usually monitored by a timer).

The session should be held continuously until the task is done. Quick breaks, like coffee or bathroom, are allowed and shouldn’t require the session to stop. Some longer breaks like lunch must be agreed between the team so that everyone does it at the same time to prevent distractions and absences.

What about productivity?

The first thing that may come to one’s mind is that Mob Programming jeopardizes the team’s overall productivity. After all, having an entire team working on the same task certainly means that both the team’s velocity and throughput will be compromised, right?

More often than not, people tend to forget that delivering a task includes a lot more than just writing code. It’s common that most of the time spent on a particular task is on coming up with the right solution or waiting for the team to review what was done. In our case, each task requires approval from 3 different people, which implies that they stop what they are doing, get up to speed, and finally review the result.

When using a development workflow like Solo Programming, once a developer puts the task up for review, the team has to understand all the requirements and review what was done, while also trying to identify what was the problem-solving process that the author took. The fact that the team has to go through someone else’s work without being completely aware of the decisions behind the proposed solution might take longer and prevent some mistakes from being identified.

Whereas when using Mob Programming, taking advantage of insights and knowledge from the whole team may lead to the task being delivered quicker while also with a better solution. When it comes to the review process, it will also be straightforward as everyone owns the decisions that were made and the solution path that was taken.

Methodology, Rules and Tools

We have been using Mob Programming for over a year. Over this period, we have been trying to refine our methodology so that we can make the most out of our sessions. Some of the phases that have improved our workflow are described below.

  1. Task scouting: each team member should, individually, check the task details prior to the session. Investing time on exploring the task beforehand will considerably shorten the time required on the next phase.

  2. Purpose clarification: at the beginning of the session, someone should present the problem at hand and make sure that everyone has a clear grasp of what the team is trying to achieve. Any questions about the purpose of the task should be raised at this time.

  3. Work breakdown: with the purpose of clarified, it’s now time to identify the work blocks that have to be monitored during the session. The different tasks that result from this analysis should be prioritized and can be split into even smaller tasks if needed.

  4. Execution: based on the tasks identified previously, the team must try to work on each task by following the agreed order. The team should expect new tasks to surface throughout the session. If it happens, the order of the tasks can be adjusted.

  5. Debriefing: at the end of the session, the team will need to look at the initially defined tasks and check if everything was tackled. The solution should be carefully reviewed together before submitting it for team review. It’s highly recommended to provide some time for an individual review to address groupthink problems.

Equally important are the rules that our team has defined so far. Periodically, we revisit them and discuss whether or not some updates are required. Trying to make this an iterative process is extremely important to enhance the overall experience of our Mob Programming sessions over time.

  1. Driving/navigation time: each team member will be in the Driver/Navigator role for 15 minutes. If a discussion comes up, the timer should stop so that both the Driver and Navigator can participate.

  2. Complete focus on the session: everyone in the room has to be focused on the session. If someone needs to work on something else, they must leave the room to avoid distracting the team.

  3. Mandatory and optional breaks: there are three mandatory breaks where the session must be stopped: morning coffee, lunch and afternoon coffee. Additional breaks are allowed but should be minimized to reduce the impact on focus. These sessions are very demanding on every team member so, if one cannot focus on the current tasks, taking a break is completely acceptable.

  4. Research time: whenever research is required, it should be done primarily by the Driver with the help of the team. Parallel research streams are allowed, as long as the team is aware of them.

  5. Identify Mob Programming tasks ahead of time: we always try to decide upon whether a specific task is going to be tackled through Mob Programming or not. It facilitates any coordination required during our sprint.

Due to the COVID-19 global pandemic, we had a new challenge ahead of us: Remote Mob Programming. As a consequence, we had to go through the rules above and update them as a means to adapt to the reality of having the whole team working remotely.

  1. Driving/navigation time: this should be increased, in our case, we adjusted it to 45 minutes, due to the extra work required when changing the Driver (e.g. setting up the environment, sync with git’s remote repository). It might take up to 5 minutes and wouldn’t be worth it to do it every 15 minutes.

  2. Video sharing: everyone should keep the camera on during the session and, when possible, look directly at it. It’s as close as we can get to face-to-face interaction.

  3. Driver handover: every time a Driver handover is required, the current Driver has to ensure that changes made during their turn are properly committed and pushed to the remote repository. To have a better sense of the changes and their history, usually, the Driver’s name is kept on the commit description.

When it comes to the tools that we use during our mob sessions, it depends on if we are doing it in-person or remotely. When having in-person sessions, the only tool that we make use of is Mobster, which allows us to keep track of the Driver timer, the active and next up Drivers. Whereas when having remote sessions, on top of Mobster we also benefit from Slack for video/screen sharing and live annotations (i.e. being able to write on the Driver’s screen) and from Trello for task management.

Challenges

The main challenge that we are facing at the moment is trying to make sure that everyone equally contributes during these sessions. Different types of personalities lead to distinct forms of contributions, as not everyone is comfortable thriving in this type of environment. However, no opinion must be left behind. Everyone should share their point of view, or we wouldn’t be taking advantage of using this methodology. The Driver usually makes sure to ask each person’s opinion to ensure that everyone is sharing their ideas and contributing to the session.

Dealing with different paces and knowledge levels is a continuous struggle until we have everyone at roughly the same level. One may be more comfortable with a particular programming language or technology but has to ensure that everyone else is capable of keeping up with what’s being done during the session. Having a person with a preconceived solution and imposing the next steps on the Driver should be avoided. The solution should be discussed and agreed by the whole team so that any participant is capable of providing the following steps.

Yet another challenge is the potential bias that comes from reviewing tasks as a group. In order to tackle this particular issue, we usually try to enforce individual reviews on top of the Mob Review.

Conclusion

Being upfront, open and honest towards the team about our feelings regarding Mob Programming and what could be improved, has proven essential to be able to use it regularly. Adopting it and coming up with our own methodology, rules, and tools was not an easy task. In fact, it has been an iterative process, and we still feel that there are a lot of challenges to face ahead of us.

Nevertheless, the impact that Mob has had on the team has been really positive. Not too long after giving it a try, we noticed that knowledge was being spread throughout the team much quicker than before. We were now becoming a T-shaped team. For instance, due to previous experience, some team elements were more prone to DevOps tasks, e.g. handling the CI/CD environment, and they quickly started sharing their knowledge so that everyone could do it on their own.

On top of that, we have seen a marked improvement in code quality, which has resulted in very few bugs after live release. Every team member agrees that the real value of adopting Mob Programming comes with being able to build high-quality software while ensuring that everyone understands the codebase and the philosophy behind it.

Particularly during the COVID-19 pandemic, where everyone has been working remotely, having Remote Mob Programming sessions kept the team together. Since there’s no in-person interaction during these sessions, we try to take advantage of the live annotations feature to make jokes and have some fun. We lose a bit of focus, but in return, the team feels closer, as if we were working together in-person.

Every two weeks, the team takes a brief look at performance metrics, like throughput and cycle time. During the switch to Mob Programming, we didn’t see a significant impact on them. Yet, the goal was never to ship code faster, but instead to improve the quality of our deliverables while also sharing knowledge across the team, even if our metrics could be compromised while doing so.

We would encourage teams to try Mob Programming and evaluate if the pros of adopting it outweigh the cons. We suggest that they start with tasks that tend to demand discussions and brainstorm, as it will have the most impact on those. We are confident that such a methodology is worth trying, and the output can be surprisingly good for any team.

Originally published at https://www.farfetchtechblog.com on December 16, 2020.