“Mob programming” - still in the comfort zone?

What is mob programming?

Julien: According to Wikipedia, Mob programming (Wikipedia: https://en.wikipedia.org/wiki/Mob_programming) “ is 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.” It is an extension of pair programming where two people are seated at the same computer and collaborate on the same code at the same time. With mob programming, collaboration is extended to all team members, while using a single computer to write the code.

"The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team – one (active) keyboard – one screen." — Marcus Hammarberg, Mob programming – Full Team, Full Throttle

But for the rest of the world, mob programming looks like one person working while the rest of the team watches them.

How did you get this idea?

Julian: After seeing the presentation Mob Programming: A Whole Team Approach by Woody Zuill at MixIT 2019, I - like many! - was very reluctant to work with five people in front of a screen. It’s often hard to change habits. You can quickly think that:

It doesn't seem at all effective ...

It's technically complicated to set up ...

It is not compatible with teleworking ...

I was still really intrigued because the presentation was very well done and very promising. And after some research and discussion, I thought that maybe after all, magic might happen...

So we decided almost a year ago to launch an experiment on one of the new features in our Bonita platform that we had to implement.

How did you convince the team to try?

Julian: It was not very difficult because we were in the middle of a team restructuring. Two new developers had just joined us. So we already had a lot of knowledge transfer planned.

The team was a bit frustrated about the number of tasks that we were trying to do - too many in parallel, and the number of interruptions that this generated. IIt was very difficult for the team to have a common focus.

And finally the fact that we run in sprints made it low risk to try. We could easily timebox the experiment on a sprint.

How did you start?

Julian: Maybe I can start by introducing the team. It is made up of five people, quite heterogeneous in terms of skills and personalities (like all the teams I imagine), including:

• Anthony, senior back end and front end developer, rather reserved Julien, myself, senior back end and front end developer, difficult to qualify
• Dumitru (alias DumDum), junior back end and front end developer, very motivated and expressive
• Bishal (alias BiBi), Junior front end developer, reserved with a very good sense of design
• Nathalie, Product Owner and ergonomist, unfortunately very unavailable

We had to design and test an application page with medium complexity, and a strong coupling with the existing APIs of the Bonita platform.

The development was done in a project built with Gradle. The page to be delivered had to be done with the UI Designer web page development tool, and the tests had to be done using Cypress.

Suffice to say that for newcomers, it was quite a lot to integrate.

After validating the objective and the methodology to follow during the sprint planning, we simply reserved a part of the office open space where we had room for five people, with a laptop and a standard size screen, and we started.

And was this first iteration conclusive?

Julian: At first glance, it was rather a success. We developed a page very quickly with better implementation, and good test coverage.

But despite this, there were some tensions or frustrations in the team:

• All cross-cutting topics were paused
• The experiment was quite trying (few breaks allowed)
• Communication was sometimes a bit rough (mix of passion and fatigue)
• Loss of attention of some team members (due to notifications from phones, by discussion going on too long)

To compare with agility, over the past 8 years we have learned in stages:

1. Start with a strong framework
2. Modify this framework
3. Abandon the frame

With our “mob programming” experiment, in hindsight I think we started directly in step 2. Unfortunately, ignoring or downplaying some basic rules meant we lost their benefit.

A reminder of those basic rules:

• There is a pilot, a navigator and researchers.
• The pilot must simply code what is asked.
• The navigator consults the researchers and gives the orders to the pilot.
• The roles must change person every 15 to 30 minutes.

So finally the result of the first iteration was rather ambiguous because we were convinced by the result, but not by the format. Despite everything, we were convinced that it was necessary to go further with this process by making adjustments to get more from it.

What have you changed in your application of mob programming?

Julien: Following the first sprint, still with the same team, we first decided to apply the basic rules more strictly.

Rotating roles regularly offers many more benefits than it seems. Among other things, it allows you to:

• Keep the attention and involvement of the whole team (knowing that everyone will have turn to be navigator)
• Help to have a good distribution of speaking time (encourage the most shy, limit the most expressive)
• Make sure that everyone integrates the work in progress (being a Navigator / Driver requires a good understanding of the work in progress)

Also giving the floor mainly to the navigator allows you to hear better the quiet personalities, and it is very important for the navigator to be able express the entire idea, even if the researchers do not agree. Indeed, learning by error can be beneficial, or maybe the researchers misunderstood the navigator’s idea.

We also learned to use mob programming more appropriately.

• For example, we didn't find it very suitable for bug fixes, which we do better in “pair programming.”
• We have also determined fixed periods for working in mob programming mode, to allow everyone to have slots available for non-sprint activities.
• The presence of Nathalie (our product owner) is no longer necessarily 100% of the time. We consult her only when we are faced with complicated choices of ergonomics, or when we are very focused on the page design.
• It was important to set more break times.

Finally, it was essential to adjust the work environment:

• We quickly swapped our small screen for a giant screen and replaced the laptop with a real desk / mouse / keyboard facing the screen.
• We also tried to find the quietest place possible.

And how have you benefited from mob programming?

Julien: We have seen a lot of benefits from the methodology.

Save time

• Avoid blockages when the team member who has the required knowledge is not available
• No more Pull Request review time needed
• Elimination of any merge conflicts
• Disappearance of interruptions between team members working on different subjects
• Reduced external interruptions (people seem to hesitate to interrupt a group more than an individual)
• Better focus of the team, so we finish things faster
• Shorter stand-up meeting (with fewer subjects in parallel)

Share global knowledge

• Same level of knowledge for all on new developments
• Ramp-up of new members on the legacy code

Quality

• Overall the solutions implemented are more qualitative (more “smart” in the implementation, better tested)
• Fewer bugs in pages delivered (which by the way is a monstrous time saver)
• With hindsight, we also noticed that the code was made in a very modular way, so subsequent modifications were very simple to do.

Team spirit

• We took advantage of the heterogeneity in the group rather than “putting up with it”
• We learned a lot about how to communicate (communication between team members is a key success factor)

So is this is the “magic solution” everyone was talking about?

Julien: Well, beyond the benefits mentioned above, and despite the initial skepticism, in the end we did find some magic there.

We have been able to see the emergence of really smart implementations thanks to this phenomenon of collective intelligence.
We also improved our daily satisfaction, by delivering things faster each day.

But the learning is not finished I think, we just reached a good cruising speed =)

But now, is "mob programming" in confinement or with social distancing possible?

Julien: Since the recent Covid-19 crisis, everyone has gone 100% telework for an indefinite period.

But luckily for us, we had reached, I believe, a level of maturity sufficient to be able to continue mob programming.

We continue to apply the basics, through video conferencing tools. The development environment must be duplicated for everyone. Communication was necessarily a little degraded due to videoconferencing. But it still works.

Above all, mob programming is learning to communicate effectively in the team. As a result, learning takes place over iterations, and each team will have its own way of understanding mob programming, whether in physical presence or telework.

For the future, I won’t make any predictions. But whatever the scenarios, we can always define periods of mob programming during which we will be teleworking, and periods of physical presence in the offices where we will apply social distancing as needed.

In general, to start mob programming, I believe that a good foundation would be to:

• Apply the basic rules very strictly
• Have a comfortable working environment (large screen, mouse and keyboard, quiet location and no ambient noise that could disrupt communication)
• Keep free time slots for everyone's non-sprint activities (email management, cross-functional projects, etc.)
• Define break times (for example, use the Pomodoro technique)

Thank you Julien for our conversation!

I now know a lot more about mob programming, and I believe that among the current development methods, mob programming has its place. I saw that it is possible to get the most out of this method, even while adapting it to the current circumstances.