Mob programming with Funnel and PyLadies

On December 1st Funnel and PyLadies Stockholm held a mob programming workshop at the Funnel office. This blog post is based mainly on the presentation on mob programming held by senior developer Sara Wänerskär and Christina Nilsson, developer coach. The contents of this blog post should be enough to get you started with mob programming.

What is mob programming?

Mob programming was first mentioned in 2002, but gained fame through Woody Zuill in 2014. This way of programming is an aspect of agile development. It is derived from pair programming, where you have two developers working together. One person, the driver, types and the other person, the navigator, tells the driver what to do. Mob programming is similar to pair programming, but with several navigators.

Setup

Mob programming includes the following:

• A group of programmers
• A problem to solve
• A suitable room
• A computer
• Screens everyone can read from
• A timer

So you have a group of developers. Their intent is on solving a specific problem by collaborating. What do they need? They need a suitable space for mob programming. They need to hear each other and not disturb, or get disturbed by, the people around them.

The programmers will be working on the same computer. There need to be keyboards and computer mice that everyone feels comfortable using.

They need to have a computer screen everyone can see. If everyone is to get involved with solving a problem, everyone needs to be able to read the code to follow the current train of thought.

The team also needs a timer. The participants will take turns to sit by the keyboard, and rotations should be timely and quick. They need to be able to switch roles without losing the train of thought. There are mob timing apps you can install on your computer, or you can use the timer on your phone.

Roles

Let’s have a look at the roles of the mob participants:

• The Driver
• The Navigator
• The Facilitator

The driver will do the typing. They will translate what the navigators say into code. The driver will not take part in discussing the solution. It is not an opportunity to code whatever you want as quickly as possible, but to listen and comprehend. If the driver has an idea, they will have to wait until it is someone else’s turn to sit by the keyboard. Being a driver can be the most restful place in the mob, despite the high level of active listening required.

The mob participants that are not the driver, the navigators, will discuss the problem and possible solutions. They will instruct the driver. The timer sets the roles, so if a navigator is interrupted by it being their turn to sit by the keyboard, they will have to wait to express their ideas. The navigators should agree on what the driver writes, and feel free to try the ideas of different participants.

Often, some people will be more experienced in the codebase than others. They can have the role of facilitator. Their job is to encourage other team members to find solutions, rather than coming up with them on their own and thus risking losing parts of the team.

The goal is to get a common train of thought and to avoid groupthink. Mob programming can be seen as a type of straightjacket to promote joint ownership and active participation from all team members. All ideas expressed in code will pass several brains, as it is not the person thinking of a solution who will type it.

Mob programming is often associated with agile development principles and uses the agile practice of the retro. What works for one team might not work for another. Doing remote mobbing is different to working with each other in real life, for example. The coders need to be open and constructive. Scheduling retros helps ensure that any problems will be caught in time.

What are the advantages?

There are many advantages to mob programming. We want to highlight three of them.

Knowledge sharing

There are several knowledge pools in a development team. By mobbing, knowledge about the requirements, what the task is really about, the technical aspect of the project and the domain will be shared within the group.

Automatic quality assurance

When the entire team understands the codebase, they will know it today as well as tomorrow. If the collaboration is successful, there will be more input on possible corner cases that the code will need to handle. This will decrease the risk of bugs and misunderstood requirements.

Finally, when the entire team has already read and understood the code, there is no need for a lengthy code review process.

Improved communication

Everyone who can have some input on the task at hand can be part of the mob. Having the entire development team speaking directly to a stakeholder is also a way of using their time better, as the questions and input will cover the case better. Apart from that, team dynamics will generally be healthier when everyone has a deep understanding of the problem. Effective knowledge sharing builds team togetherness and decreases the risk of the team being too dependent on an individual.

What are the challenges?

There are a couple of challenges to this way of working. It is the responsibility of everyone to make it work. You need psychological safety to say that you do not understand something and that you need to take a step back and look at the problem again. Let’s look at three challenges you might face when experimenting with mob programming.

Patience

If you are an experienced coder who is used to both the technology and the domain, you need to fight the urge to solve the problem as quickly as possible and channel your energy into giving other team members the opportunity to come up with a solution. Killing your darlings, or saving them for a later date, can be frustrating. You want to achieve flow in the team, not individual flow.

Research

Also, tackling issues that require a great deal of research can be cumbersome when working this way, especially if the groups are small. Woody suggests having extra computers in the room for this purpose, but that might not be suitable if the group is small. Again, you need to be honest and open and constantly evaluate how work is going.

Energy

Practising humility, courage, speaking in groups, and active listening takes a lot of energy. To make a mob effective, you need to take regular breaks and be aware of when you are starting to zoom out. Finding a good way of working together can take time, so it makes sense to make practice mobbing a separate activity, to practise social interaction before applying it to real business problems.

How do developer teams at Funnel work with mob programming?

All teams at Funnel collaborate a lot. At the beginning of the pandemic, many found collaborating remotely challenging. Today, teams collaborate a lot, using different tools such as VSCode and its session sharing functionality. It has been an iterate and learn process. Some team members prefer not to have a camera on all day - and that is ok.

Christina Nilsson is coach for the Plugin E-Commerce team. This four-person team has scheduled mob time between 9 and 15 every workday. They also have a micro retro at 14.45 to reflect on the day. During mob time, the team solve issues together. They do not only collaborate on building new functionality, but solve support issues together. This means that when they respond to customers, they write the response together, just like they write the code together. Outside of mob time, team members have alone time where they can focus on different kinds of learning or just regular work issues during alone time. Any regular work solved alone is then shared with the others during the morning sync at 9. They strive to get everyone in the team up to speed with what is going on, and do things at a pace where everyone can follow. They believe that this builds a stronger team and better code :)

Final words

In the example above, you can see that the E-Commerce team has found a way to collaborate using mob programming that suits their needs and energy levels. Our hope is that anyone interested in mobbing can start off by using the guidelines in this blog post.

There are three roles you need to remember:

• The Driver (typist)
• The Navigators
• The Facilitator

Not all groups may have a facilitator. If you find that other people are finding it more difficult to solve the problem than yourself, you should try to help them come up with a solution rather than pushing for your own - that makes you a facilitator that keeps everyone on board.

The driver will express the ideas into code. When it comes to instructions to the driver, the level of detail can vary and is one of those things that might need to be adjusted with time. Navigators will discuss the problem and agree on which solution to try. During the PyLadies workshop, we used simple Exercism katas. You may want to try using small exercises to practise mob programming too.

• One team
• One task
• One set of hardware
• One driver
• Several navigators

Another thing to point out is that the point of this exercise is to have a good time and to get to know each other. The goal is to have everyone on board, and that means that the code you are writing will look different to what you might write when sitting alone. This is not an opportunity to showcase your rockstar coding skillz, but to look out for your teammates, practise active listening and creative thinking.

Good luck and have fun!