Try Mob Programming to Inspire Team Growth

Whenever I go to a conference, I try to leave with one new idea that’s both exciting and a little too far out of my comfort zone for me to be ready to try it out instantly. One of these ideas was mob programming.

I was introduced to this concept by Woody Zuill. He stood up, faced the room, and said he would show us a short video, then share the story of how his team had been working for the last two years. We watched time-lapse footage of a day in the life of a team that spent the whole workday sharing a single keyboard in front of a dual-projector PC setup—and I was sitting on the edge of my chair. Could a whole team really share a single computer all day, every day, and show enough benefit to receive permission to do it for two years? By the end of the half hour, I was convinced that Zuill’s team had, and I was incredibly excited by the possibility.

Of course, there’s a gap between excitement and reality. While I believed in the concept, I couldn’t imagine convincing one of my clients to let me try it out. I restricted myself to dangling the idea (and the video) as an “out-there possibility” in the training room when people were questioning the idea of pairing.

A year later I got to spend more time with Woody and also met Llewellyn Falco and Mike Bowler. Falco shared ways he had been using mob programming as a technical coach (Zuill actually credits Falco with the original inspiration), and Bowler gave me a concrete example. He was teaching agile development practices as part of a large banking transformation at the time and would follow each agile dev course by spending two days mobbing with the dev team, working on their own stories to embed the techniques. The teams then had the choice as to whether and how to continue using the technique in their day-to-day lives, and he was finding it incredibly effective.

This April, it all tipped for me. Seventy enthusiasts gathered at the Microsoft New England Research and Development Center for an inaugural mob programming conference. This was not just theory; it was a lot of people using this method in their daily lives and sharing ideas and techniques for how to practice it. After some great workshops on how to introduce and facilitate mob programming and some practical suggestions on the use of coding kata as the introductory technique, I was finally ready to step into it.

A week later, I had facilitated my first mob programming session to an extremely receptive dev team, and it was all good. I have used it at every opportunity ever since, and I’ve found dev teams and supportive management who can see the difference it is making in their teams’ lives.

Introducing Mob Programming to a Team

Getting started is simple. I usually begin with a ninety-minute session and a group of five to eight people (a dev team or community of practice) around a computer, preferably with two projectors to provide dual screens. It’s great to include non-devs, too. Introduce the driver-navigator paradigm from pairing and explain that we have four to seven navigators and just one driver. When you’re at the keyboard, it’s your break. You’re just the input device; all the thinking is done by the navigators.

Use a three-minute driver rotation. (The guidance from experienced mobbers is that it takes about six months to reach a fifteen-minute rotation.) Pick a coding challenge to solve that’s appropriate for the group. For me, it’s usually something to do with helping a team grow in their automation skills. My favorite tactic is to implement FizzBuzz using test-driven development, or to explore some deeper concept like approvals or evolving from the use of page objects to the journey pattern. Run for about an hour, then chat about what you’re learning. Watch as people start to talk about insights, development standards, and learning from each other, and the time flies by.

What happens next varies. Most teams agree that mob programming is a great idea and start to schedule regular coding practice sessions, or coding kata. Topics for these regularly self-seed. At the end of my first test-driven FizzBuzz session, we started talking about potential refactoring, and the topic of dealing with string constants came up. It turned out the team had three different approaches to handling string constants, so the next session became an exploration of string constant techniques that supported internationalization. At this point, you have a team that is regularly devoting time to improving their development practices, and very good things happen!

Then team members start to mob every time they have a tough problem to solve or a new technique or tool to experiment with. They start to pair more—it’s a great way to model effective pairing practices. Their code quality goes up. They start to put more effort into aligned dev standards. Cultivating cross-functional skills goes from something the team talks about every retrospective and never follows through on to something that happens naturally. Nontechnical people also love mobbing, particularly testers. They learn how to read unit tests and drastically cut down their manual testing efforts, safe in the knowledge of what the unit tests have covered.

I don’t yet have a team that mobs all day, every day, but I can see it happening. It’s a safe way to explore new techniques and grow. And the biggest surprise to me is that management takes very little convincing. The benefits are obvious, and I suspect that by the time any team is ready to want to mob all day, the early benefits of their part-time mobbing will be evident enough that they will encounter very little resistance.