This April I’m heading over to Boston for my first mob programming conference. I’m even running a workshop on the power of refactoring as a team. It should be a blast.

It’s had me thinking too. How did I get here? When did I start mobbing?

My first attempt didn’t bear the name mobbing, but it had some of the hallmarks. I was into running coding practice sessions called Coding Dojos. The idea was to spend two hours together solving a problem in pairs using TDD and object orientated design. I heard some folk in Finland had invented a variant called ‘Randori’ - a martial arts term for multiple attackers - where the entire room worked on one computer.

I gave it a go in 2009. Twelve eager people came along.

It was a disaster. I didn’t have the facilitation chops to coordinate that many developers behaving in this new way. The person at the keyboard would go off on a tangent, and the mob would lose interest. I chalked it up as a learning point. And never tried the style again. It could never be productive I figured.

Fast forward six years and I’m working at ThoughtWorks. My good friend Adrian who works in the same city tells me that they have begun using mob programming in their teams. I have flashbacks to 2009 and look incredulous:

Joe: “You are working together the whole time?”
Adrian: “Yeah, five of us.”
Joe: “Like, programming on one computer?”
Adrian: “Uhuh.”
Joe: “Ok, you mean, you get together on a big story and split it so pairs can work on it?”
Adrian: “No, we might split the work, but there’s only one computer being used to write the story.”
Joe: “And, this is productive?”
Adrian: “Yeah, come and see us if you want?”

So I did.

Then I asked if I could go work with them.

Funnily enough, they interviewed me in a mob setting too. The team wasn’t told I was there for an interview and assumed I was visiting again. Thankfully they were a considerate bunch and made it a fun experience.

Six months into my new job I got a chance to join a new team. This team looked after the Sales system and worked in a different silo from the mobbing teams. It was the traditional solo developer getting work done without code reviews set up. Quite far away from the rest of the organisation.

I joined the team the same day as Kevin Rutherford joined them as a part-time consultant. He felt that mobbing was the best way for a team to work together. So we did for a week until Kevin had to leave.

There was tension and trepidation in the air when the team returned on Monday. Are we still going to work this way? Kevin’s not here now so we could revert to type. But we decided to give it another four weeks until Kevin would return to help us again.

That was back in 2015, and that team has been mobbing ever since. It may be the longest-serving mob in Scotland.

Mobbing gave that team some significant advantages:

  • Learning new skills all the time from each other
  • Brought the business knowledge of a complex system together - making it easier to complete tasks
  • Making decisions about how to improve the architecture as we went

The team went from taking weeks to complete stories to hours. In fact, we had to agree to slow ourselves down as we’d gotten so good at cranking out features. We used the extra time to improve as we went. Adding 30 minutes to the end of each task to clean up given what we learned.

Eventually, the management track came calling for me, and I had to leave. But that team remains one of the best learning experiences I’ve had in tech.

Reminiscing has gotten me excited about the conference and the renowned mob programming experts leading the sessions. From Woody Zuill who popularised the method and Llewellyn Falco who gave mobbing its core practice of strong style pairing.

I’m looking forward to Dawna Jones’ session on ‘Using Conflict to Extend Collaboration Skills Needed for Mob Programming’ and seeing Jessica Kerr guide us to mob in a new language.

If you can make the conference, then I’ll see you there. If not then give mobbing a chance. It took me six years, and I don’t want to go back.