Mob Programming: implementation and lessons learned

We welcome the contribution of a guild of the Intré team on our blog. They wrote an article on Mob Programming after attending our workshop with Woody Zuill, one of the pioneers of Mob Programming.

The guild has been working using Mob Programming for the four months after the workshop, and this article explains a bit more about what they did and what they learned from it. Enjoy!

Ever heard talking about Mob Programming?

It’s a software development practice that teams use to work together by actively collaborating whilst having fun.

What does Mob Programming mean?

Mob Programming is a software development practice where all team members work together on the same activity using the same computer at once.

In Mob Programming, one person sits at the keyboard while others give s/he directions on what to write. The session is open to other roles, too (it’s not exclusive for software developers), such as product owners, scrum masters, business analysts, Q.A., stakeholders and anyone who might be helpful in the overall development of the project.

Mob Programming has gained popularity within the industry over the past years, even though working methods from other sectors inspired it. Each group of people who are actively working to execute a (more or less) complex task is doing some sort of Mob Programming.

The "driver and navigator" pattern

The interactions between who writes and who drives follow the “driver and navigator” pattern.

How does it work? See the example below.

Let’s imagine we’re in a car: one person is at the steering wheel and is solely responsible for actually driving the car, whereas the other person, sitting beside him/her, can read the map, leads the way, informs about risks, suggests alternative routes, and so on. The person checking the map has a clear idea about the itinerary and the streets ahead, and in this way, s/he can provide all the needed information to the driver.

Similarly to this, in Mob Programming, the navigator - aka the one reading the map - is focused on the final objective of the software project. The driver - aka the one driving the car - can use all the best strategies to translate into code the instructions received.

This kind of interaction requires a certain level of balance: it might be the case that the driver is an expert one and knows the streets very well. In that case, a high-level indication from the navigator such as “take the highway and let’s go to Milan” will be sufficient. Some other times, a more specific indication such as “reach the traffic light then turn right to take the highway” might be needed, or something even more unambiguous if the driver is very inexperienced, such as “press the clutch and engage the first gear”.

Smart input device

The driver’s role is to incorporate the navigator’s instructions and translate them into code, and s/he has to do so by avoiding taking part in the conversation or taking the initiative.

The driver behaves like if s/he was a device receiving vocal inputs (such as Amazon Echo or Google Home), but more clever: s/he can translate concepts, even business concepts, into code.

As a qualified and experienced person, s/he can translate the indication “multiply the value of each product in the shopping cart by its quantity and then print the total” in an implementation where s/he write a cycle where s/he increments the “sum” variable, or with a “reduce” operation, or with a recursive function.

The basic principle governing the driver’s role is this: for an idea to enter the codebase of a project, it has to be written by someone else. In this way, the idea is shared, discussed and validated, and we’re making sure that it is understandable simply because someone else implemented it.

It’s quite a simple idea, but this is the core concept of Mob Programming.

Let’s dispel some doubts about Mob Programming

As we were working using Mob Programming, some objections arose. Let’s see them. We’ll also share some of the possible solutions and alternative ideas we came up with and explain our doubts.

"Mob Programming is not effective."

It depends.

In terms of effectiveness, Mob Programming helps maximise the flow, which is another way of saying it helps to minimise the time between the start and the end of a sprint’s story. In Lean terms, we’re minimising the waste.

For achieving this, Mob Programming gathers in the same room all the people needed to bring the story to its conclusion. Nobody has to wait for anyone else as everyone is working on the same activity.

However, to fully understand what effectiveness means in Mob Programming terms, we need to think about who’s joining the Mob Programming session.

"I don’t know who should join the Mob Programming session."

The answer to this doubt is: all the people who are needed to close the activity and, ideally, all the people who can contribute to the problem’s solution (including, but not limited to, PO, stakeholders, final users, software developers). Any impediment that may arise during the development has to be solved exclusively by the people in the session.

"Well then, I’ll invite everyone… just in case."

Ok, that’s the ideal situation.

There are a few risks, though, such as:

• Who’s taking part in the session without being able to contribute might be wasting his/her time (such as a designer on a Mob Programming session on setting up GitLab pipelines)
• Loads of chaos resulting from having too many navigators can slow the flow down: put extra care in facilitating the conversation and controlling the scope. The more people want to participate actively, the more you’ll have “noise”.
• Having too many people can lead to an ineffective session: each person’s contribution diminishes as the number of participants grows. Adding a third person to a paired activity will surely fill in some gaps, but adding a tenth person to a group of nine won’t make a big difference. Consider that this tenth person might create more value somewhere else.

"I think it’s a waste of time. By working on our own, we carry on more than one activity at the same time, and not only one."

Let’s imagine we have a high-quality backlog: the story on top of that backlog will have the highest business value. It might make sense to bring that in production before anything else and despite all other stories.

On the one hand, Mob Programming can be a helpful tool to concentrate all efforts towards a single objective: maximising the business value as soon as possible.

On the other hand, if the backlog doesn’t have clear priorities, there might not be considerable advantages in using Mob Programming. For example, in one case, you might need to try different add-ons to the system to identify which one is the most valuable. In the latter situation, many developers working on different parts at the same time might be a more effective solution than working as a mob.

There’s another scenario where we might need to assess if Mob Programming is the right approach, according to the team’s objectives: when the team works on releasing an MVP. What is more important: building many small parts within the system (even separately) or creating a shared knowledge with few implemented and high-quality stories from the start?

“But if I don’t know the actual priorities, during the Mob session, people might be working on the wrong thing. And if the PO doesn’t join the Mob, I might not have the answers I need. And…”

Yes, life is complicated.

To work well, aiming for ideal working conditions is always of great help. Some of these conditions are:

• Clear priorities on the project
• "Customer on-site", aka having the client at disposal and, if possible, physically near to the team, at all time
• No external dependencies (such as no third-party libraries included in the source code)
• PO and Scrum Masters within the team
• Rapid feedback on the stories completed during the last sprint.

If the context you’re working on is sub-optimal, then all other development models won’t be top-notch.

Our experience

During our guild, we joined Woody Zuill, one of the pioneers of Mob Programming, for his workshop on Mob Programming organised by Avanscoperta, and we’ve been experimenting with Mob Programming for the following four months.

After each session, we did a retrospective. Thanks to these, we’ve elaborated some insights on the pain points encountered along the journey.

For Mob Programming to be effective, the team needs to work well together. These sessions amplify the social and relational aspects, and they need to be monitored, even by making tweaks and adjustments along the way.

Let’s have some rules and measure the interventions.

Not having discipline in how one or more navigators intervene and give instructions is a clear example of dysfunctional dynamics within a team. This might result in the session losing its purpose as it might not be clear anymore what the overall goal was. Navigators must learn how to make their interventions in the most effective way possible to bring value without causing confusion.

The Coding Dojo has been beneficial in this sense, and we’ve experimented a lot with it. There’s only one navigator per shift in the Dojo, and all other participants can’t give indications to the driver. In this way, people become aware of the necessity of thinking before talking so that each intervention can be useful and not just noise.

Let’s give room to everybody.

Another thing to keep an eye on is how much people participate in a session and if there’s someone who is too active while others don’t want to intervene at all. We suggest that each team finds some ways to correct this behaviour. For instance, on some Mob Programming sessions, only the shyest folks acted as navigators.

Careful with the “flock effect.”

The flock effect has to be kept under control too: you don’t want too much uniformity within the contributions. This might mean that no alternative solutions are taken into account. This might result in losing one of the key advantages of Mob Programming.

Find a balance as well as the right amount of communication between driver and navigator

The balance between driver and navigator requires good communication: the driver can ask for more specific indication if needed. The navigator can correct the navigator’s route if s/he is going in the wrong direction and so on.

As we were working with Mob Programming, we’ve seen that giving high-level indications to the driver is the best choice, as the navigator can then narrow them down and provide more detailed info only when this is strictly required. This has some cool advantages:

The exchange between the driver and the navigator remains on a higher level, which gives priority to the content rather than to the implementation details.

The navigator can be a person who does not know about programming

If the driver is quite expert, s/he can significantly contribute without being limited by the specific indications provided by the navigator. For example: if the indication is “write a for cycle”, the driver is being forced to execute these instructions, even though s/he might think that a “map” might be more effective in that specific situation.

Other advantages of Mob Programming

Here are some other significant aspects we want to highlight about this practice:

• It helps different ideas and points of view flourish
• Immediate feedback
• Fun and engaging
• Code review and merge request become useless
• The cognitive load is shared
• Collective code ownership ➡ nobody can say, “I didn’t do it”.
• If a person needs a break, this can happen without interrupting the work of the team
• It helps to share knowledge within a team.

Conclusions

Mob Programming is not a “solution”: you don’t need to use it all the times, and it’s best to assess if it can bring more value depending on the situation and context. It can be an excellent alternative to other software development practices such as pair programming.

Mob Programming is a “tool”: it’s good to learn how to use it by defining few basic rules and practising it in order to find the most suitable setup for your team.

The Intrè Guild team members, and writers of the article: Damiano Salvi, Manuel Togni, Alex Mufatti, Francesco Sacchi, Marco Testa, Luca Marcato.

This article first appeared in Italian on Intré's website.

Cover by Jean Frederic Fortier on Unsplash.

Learn with Woody Zuill

Woody is the trainer of the Mob Programming workshop.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.