On Mob Programming

I’ve had the opportunity, as part of my current role, to take the team through the exercise of mob programming. TL;DR – a whole bunch of people working from the same computer/system on the same problem with one person typing, and one primary person giving direction. Sounds a little crazy at first blush, but bear with me.

There are several takeaways I had from my time running/taking part in those sessions. Overall, it was a very enjoyable process, and a tool I hope to continue employing in the future. (Anyone looking for the highlights can jump straight to the Takeaways section.)

Background

First off, hat tip to the author of https://beardedprogrammer.com/, who I believe was the presenter at Indy.Code() when I first heard mob programming discussed in depth in 2018/19ish. I had trouble digging up my notes from the event, so I may be misremembering that. Several folks from SEP presented solid topics in the conference’s first few years, so it all kind of blurs together.

Anyhow, at the time, I was in a consulting role, and thought the idea of mob programming was intriguing, but not something I would be able to employ. Not a lot of folks want to throw money at a bunch of consultants standing around a screen. (In hindsight, some clients might have, had I been able to articulate the benefits as I can now).

First Foray

Flash forward to my current role circa Summer 2021. Early on, another teammate used a mobbing-but-not-quite approach for introducing us to the code base and the business domain. I found it somewhat helpful, but not quite. The main area lacking was that the greenhorns never got to take the driver’s seat.

Jump another month or two, and I’m on a new team with several other new-to-company engineers. We were all tasked with picking up a new internal framework and new-to-us language (Python).

I wasn’t super familiar with Python, but I had more dynamic language experience than the rest of the team, and also the most industry experience overall. So I decided to take another stab at mobbing, but with more interaction.

In practice, I lead the group (myself, one mid/senior-level, and five juniors at peak) through hour-ish long sessions working together through a ticket.

The first several sessions went…okay. There were some definite pain points, but we made progress on tickets, and I could see several on the team becoming a little more comfortable with the code base.

Refining Approach

After that first wave, I decided to do a bit of digging and see if I could find some more informed perspectives on mob programming. I ran into this excellent post from Shopify which resonated with a lot of what I was observing.

One issue that popped up was general fatigue. Everyone on the team felt it. Our early sessions were running 1-2 hours. Once we discussed it, we realized its still, at its core, a meeting. Just a really dynamic one. But that being the case, we decided to cap it to an hour. This served really well.

The next big issue I noticed was general zone out. Happens in any meeting, of course, but extra tricky for an interactive meeting like mob programming. This is where the Shopify article came in particularly helpful, suggesting a capped driver/navigator rotation. Our team found about 20 minutes was ideal. Enough time to get comfortable and make headway, but not enough that everyone was zoning out.

Introducing those two timeboxing elements gave it much more traction for the team. Much more participation overall, more discussion, quicker transition between drivers, more volunteers for driving. And a general mood of camaraderie as we all worked together tackling a problem.

However, topics covered during sessions weren’t quite as sticky as I’d hoped. So, the last main challenge to tackle was that of navigator rotation…

Next Steps

As we continue utilizing mob programming, my hope is to relinquish the navigator role much more frequently. In the early stages, I took up the mantle because no one knew Python, and most on the team seemed generally uncomfortable with the idea. However, as time has gone on I’ve realized I’ve stepped in when silence would have served the team better.

Takeaways

• Great for introducing a new developer to a codebase and team
• Great for getting non-developers involved in the process, earlier iterative feedback
• Great for building camaraderie with a remote team

Essential for Success

To make those takeaways possible, there’s several things I would say are fundamental to see mob programming flourish within your team.

• Regular rotation of driver + navigator
• Firm time limits for sessions
• Fairly well scoped work

With those items in place, grab your pitchforks and break out a mob!