Mob Programming, a quick start guide
What’s mob programming? How can you put it into practice? How can it be done remotely?
Programming alone is good, in a pair it’s even better. But with the whole team, it’s the best! The purpose of this article is to explain what mob programming is, what you can expect from it, how you can implement it (even remotely) and what our feedback on this practice is.
What is it?
The whole team gathers
around a single computer
and works together
on a single problem.
The main idea behind mob programming is to gather the whole team around the same computer to work together on the same problem. Different team members take turns “driving” the computer, while other members of the team help think through the problem and find solutions.
What can you expect from it?
The first benefit of the mob is to strengthen the relationship between team members by working together. The mob session is a dedicated time during which team members will work together, share, confront and discuss their ideas. Ultimately, they will co-construct their solutions and this process will help the team bond with each other and build trust.
The second benefit is to teach other team members various technical skills. During mob sessions, the person driving will need advice from other team members. And this exchange will produce “wow” moments where members will be able to exchange on different subjects like architecture, design patterns, best practices, IDE or project configuration and so much more… In short, mobbing allows both to transfer knowledge and to ask other team members questions.
The third benefit is to share ownership of decisions. In the mob session, team members always share and discuss multiple possible solutions. As a team, you choose together which solution is the best in the current context. It’s important that all team members agree to the solution, because that’s how the code becomes shared by everyone. This allows everyone to maximize their knowledge of the code base and to intervene serenely in the application.
The fourth benefit is to improve the quality of the code. During a mob session, all team members focus their attention on the same part of the code, this encourages people to give their best and to produce good quality code. At this point, it should be noted here that mob programming is a practice among others, and it is very easy to combine with software craftsmanship practices such as Test Driven Development, Acceptance Test Driven Development or Behaviour Driven Development.
The last benefit is the opportunity to slice the stories into smaller pieces. In the context of our team, we often use our mob sessions to tackle a big story, think together about the architecture and how we want to implement it. By starting the implementation together, it is much easier to divvy up the work between ourselves, because everyone knows exactly how his subpart should interact with the others.
To summarise, mob programming brings:
- Team bonding
- Knowledge sharing
- Ownership sharing
- Better code quality
- Ability to break through large tasks easily
It is quite difficult to measure the outcome of these sessions in relation to the different objectives.
The first way to measure the effect is to ask the developers what they think about it. In our case, mob sessions have been very popular each time a new member joined the team. Because it allowed us to discover the code base, to explain our development practices, to co-construct solutions with people who have been around for only few weeks.
Another way is to see how the team is aligned with the quality of the code. For example, when during a refinement meeting all team members remember a part of the code they implemented together, and everyone can explain the work to be done in a few seconds.
You can also look at the team’s atmosphere. It is very difficult to quantify but for us, mobbing is a social and collaborative activity which is fun and has a positive effect on the team’s spirit and dynamics.
What are the needed roles?
There are two main roles:
Driver
The first main role is the driver who is the vector of everyone’s ideas and the only person who can interact with the code and implement the navigators’ next moves. The important thing is that s/he can’t run away with the code, meaning that s/he has to follow the navigators’ instructions and not go alone too deep in the code without explaining what s/he is doing.
Navigator
The second main role is the navigator. During the mob session, all members who are not drivers are navigators. This role is to co-construct the plan to get to the destination and communicate it to the driver. The plan to reach this destination can take many forms, it can be a UML diagram, an exhaustive list of all the different places in the code to be modified or simply a diagram scribbled on the board. The important thing is that all the people in the mob understand and agree with what we intend to do.
Apart from the 2 main roles of driver/navigators, other members of the mob may temporarily take one the following roles :
Scout
The scout’s job is to look ahead and anticipate problems that the team might face soon. S/He is here to try and find other paths to the solution. In our team, a developer often takes this role to validate technical points related to our problem. This is the only time when a person, other than the driver, can use his own computer. Once the answer is found, the scout shares his/her findings with the rest of the mob and comes back to actively participate in discussions.
Facilitator
The facilitator’s job is to ease the communication and foster good dynamics in the group. S/He is also here to ensure that the rules are respected and that no one is sidelined. This means that both driver and navigators understand the team’s choices, and that everyone has had the opportunity to share their opinion. S/He is also here to ask powerful questions like “Are we happy with the code as it is?” or “If we do it this way, would anyone see a problem with it?” Remember that we are talking about roles and not people. Anyone can play this role at any given moment. Obviously, if you have a Scrum Master or facilitator in the team, this role will be much easier for them.
Housekeeper
The role of housekeeper is to keep track of the work to be done. Sometimes, in order to allow the mob to progress on the elements that give the most value, we decide to put some tasks aside. The housekeeper is here to ensure that these points are not forgotten. These can be To-dos in the code, methods that need refactoring, or documentation that needs updating.
In the end, s/he is here to make sure the codebase remains in a clean and maintainable state at all times.
How to proceed with it?
If you can do it in a co-located space, you will need:
A space to gather together — it’s good to have enough space to allow people to move around and swap places. A funny fact is that by just moving you can see the problem from a new angle and find new solutions.
A large high-quality screen — it depends on how many people take part, but the use of a big screen will allow everyone to see the code clearly and interact with the driver.
A reserved time slot — the time for the mob is reserved specifically for this. It means that during the session, everyone only works on the problem at hand without being interrupted by external events.
Somewhere you can write — in our offices, not only do we have room to move, but we can also write directly on the walls. This allows us to share our ideas much more easily and iterate on each of them.
A set of rules — like with any practice, the team must have rules and follow them. For example, here is the list of our team rules for the mob :
- One place, one computer, one problem
- One driver, several navigators
- Rotate every 10 minutes
- The driver can’t run away with the code
- Don’t leave someone sidelined
- Take a break after each complete cycle
- COMMUNICATE!
Something important I would like to highlight, is that each team is unique, start with standard rules then inspect and adapt your way of working as you go along.
A benevolent professional team — this is probably the most important thing. The mob session will only be a success if all the participants share the values of openness and the desire to co-construct the solution all together.
If you can’t do it in a co-located space, because of COVID-19 for instance
You will still need a reserved time slot, a set of rules and a team of benevolent professionals. For the other points, it’s all about adapting to working remotely.
The first thing that you will need is to be able to talk and see the other team members of the team. For this, we use BlueJeans or Microsoft Teams.
To develop code on the same code base, we use either CodeTogether or Code with me with IntelliJ IDEA. These two plugins work pretty well; it’s not as good as being shoulder to shoulder on the same keyboard, but at least it works.
In order to share schematics and co-construct solutions, we use a Mural board. Mural like Miro are online whiteboard platforms. This tool allows us to see and time driver’s rotations, to have the list of our rules and finally to have a dedicated space to brainstorm. We use this Mural template for each of our session. Feel free to use it too!
Of course, it’s easier if you have several screens :D
Lesson learned
What type of tasks are suitable?
At the beginning, we started our mob sessions with certain types of tasks such as new technical tasks, defining the architecture, or tasks that allowed us to teach other team members. We had identified these tasks as the ones that would give the most value in terms of collaboration and skill improvement.
After several sessions, we tried with other types of tasks. First bugs, because we realized that some parts of our applications were obscure to all of us and by following the thread of a bug it allowed us all to better understand the whole application. We then tried mobbing with the tasks related to infrastructure and DevOps work; notably, we took advantage of the implementation of our first applications deployed with Kubernetes to define together the continuous integration flow and the configuration that goes with it.
We then continued with refactoring tasks or reviews and we realized that any type of tasks was suitable for a mob session. Some were more obvious than others, but we warmly encourage you to try mob programming with everything and see what happens.
Rules
We scrupulously followed the guidelines we had set for ourselves. The goal was to have good group dynamics during our sessions. However, after several sessions, we made a few changes.
The first one was to allow the usage of other computers, which made it easier for the scout or housekeeper to perform their roles.
The second change was to ban chat, email and other distractions. The goal was for everyone to be involved in all discussions and stay focused on the current work during the session.
The last change was to update the frequency of these sessions from ad hoc sessions to regular weekly sessions. This enabled us to book dedicated time in our agendas and to identify tasks during the sprint planning which we wanted to tackle together as a team during our mob session. With this frequency, the first session now takes place just after the start of the sprint. It’s often during this session that we slice down big stories into smaller tasks and start implementing them together. This is also the right time to align everyone on the architecture we want to implement.
The second session happens at the end of the sprint. At this point, we try to finish the stories that are still open and might not be completed by the end of the sprint. If the sprint is on track, we use this time to do katas or experiment with particular practices we want to put in place such as Test Driven Development.
Number of people
It is difficult to give a minimum or maximum number of people working in a mob session. It will mainly depend on the size of your team. We have tested it with 3 to 8 people. Obviously, the overall experience of the session will be completely different based on the number of people present. The fewer people there are, the easier the communication is and the more often the role of the driver comes up. With 8 people, the facilitator has a lot more work to do to make sure that everyone has a chance to express their point of view and stays on board. For us, the ideal size is 4 or 5 people as it ensures the communication remains effective.
To Conclude
To conclude I would say: just experiment with it and see if it works with your team. You might need several sessions before getting your first “wow” moment, but you will probably see value from the first session.
It’s also easier if you can be accompanied by a facilitator or someone who has already taken part in mobbing so that they can give advice during the first session.
About me:
I am currently a Scrum Master at Pictet Technologies. Before this, I worked as a developer for over 10 years in various industries in Luxembourg. Software Craftsmanship, DevOps and Agile development pushed me towards more and more Agility, which made me transition to the role of Scrum Master in 2021. Human interaction is one of my driving forces and what makes me enjoy my work on a daily basis, and that’s why a practice like mob programming is so important to me.
