Considering Remote Mob Programming in a High Stakes Environment

Write for InfoQ

Remote mob programming helped a team in a high-stakes environment to be resilient, work under pressure, and deliver successfully. Setting expectations on the first call and being serious about the reasons for doing mob programming ensured that the team kept doing it.

Giovanni Asproni gave a talk about remote mob programming at XP 2023.

Asproni mentioned that they had some strong constraints in terms of quality, security, and accessibility and, at the same time, very high visibility—especially for failure, which would end up in the news. They also needed resilience, therefore they couldn’t afford to depend on any specific individuals. So they figured out that mob programming was the way to go, despite being in a high-stakes environment, Asproni said.

As the designated tech lead, Asproni had set his expectations on the first call with the rest of the team:

We needed high quality, full automation, four-eyes principle, collective ownership, collective accountability, and teamwork—job grades were irrelevant (mine included), what counted was a contribution towards reaching the goal.

They had very little time, about half of their best estimate, Asproni mentioned, and the release date was announced to the public.

Being serious about the reasons for doing mob programming and about the expectations they set for their work was important to assure that the team kept doing mob programming, despite being under pressure, Asproni mentioned.

The urgency of a situation can take a big toll on well-being. Mob programming worked out well for them, Asproni said, it enabled them to work effectively, without cutting any corners, and keeping quality high, for long hours under pressure.

InfoQ interviewed Giovanni Asproni about his experiences with mob programming in a high-stakes environment.

InfoQ: How did you prepare and set things up for remote mob programming?

Giovanni Asproni: I made sure the team had the authority and the autonomy they needed to make decisions without me for a couple of reasons: I had to attend many meetings each day and I didn’t want to become a bottleneck; and they had better knowledge than me in many respects.

The main challenge was for me to make sure I walked the talk–by giving space to the team and trusting them to do the right thing, and avoiding any inadvertent mistakes that would have invalidated the expectations I set with them. I attended the mobbing sessions as often as I could, but not as often as I wished, as I was generally busy with calls with all other stakeholders.

InfoQ: What made the team continue to do mob programming, despite being under pressure?

Asproni: Most people say all the right things, then, when the pressure mounts, panic and do something else—cut corners, forget about automation, "parallelize" work by giving different tasks to different people, etc.

In our case we were convinced we were doing the right thing, so we kept doing it. The fact that we were distributed helped, since nobody outside the team could see how we were working, so had no reasons to panic.

InfoQ: What’s your advice to teams that are considering doing remote mob programming?

Asproni: Go for it. It will be intense, especially at the beginning, so take breaks. Don’t worry if your team does it differently from others, each team has to find its way. The speed, quality, and job satisfaction you will achieve will surprise you.

Related Topics:

• Culture & Methods
• Remote Developer
• Agile
• Quality
• Agile Conferences
• Mob Programming
• Teamwork

We protect your privacy.