Mob Programming

What is mob programming?

Mob programming (or just “mobbing”) is a technique where the entire team works together on a single story at the same time, on the same computer. It takes pair programming to the next level by including everyone.

Mobbing comes out of work that Woody Zuill and his team pioneered at Hunter Industries and is quickly spreading across the industry. We’ve been using it in our practice for several years now and find it to be one of the most useful tools we have.

Having trouble visualizing what this would look like? Check out these time lapse videos from the team at Hunter as they do mobbing for an entire day.

Why did we start using it?

When teaching classes, we would often find that attendees would demonstrate their proficiency with specific skills while they were with us and yet they wouldn’t apply them when they returned to their normal work.

To solve this problem, we’ve adopted mob programming as the second part of our training. In this way, the team will learn concepts during training and will them apply those concepts on their real code during mobbing sessions. We’ve found this to be far more successful than just training alone.

After a team has spent a few days mob programming, we find that they’re far more likely to be using the skills that they learned in the class. They’re also learning more from each other and generally having more fun.

Note that this assumes that the mob programming session is facilitated by the same people who had taught the class and that those people are continuing to reinforce the material that had been taught, throughout the session.

In additon to training, we tend to use mob programming during coaching as well. The benefits of this technique are significant.

Scheduling and advance preparation

  • Book a meeting room to take the team out of their normal environment.
  • There will only be one computer in use so a projector will be needed. Two projectors connected to the same laptop would be even better.
  • Lots of whiteboard space is recommended as the team will likely want to do a lot of brainstorming.
  • Tell all attendees to decline all other meetings during those days.

Mobbing Ground Rules (to be shared with the team)

  • Only the one laptop connected to the projector is open. All others are closed.
  • Set your Out of Office reminder if you are mobbing for an extended period of time. For example, a full day or two.
  • If you anticipate emergencies, feel free to tell people where you are. They can come and knock on the door if they really need you and that has happened a couple of times for us.
  • We rotate the keyboard at least every 15 minutes so everyone gets a chance to type. With larger teams, we’ll often start with 7 minute rotations to ensure we get through the entire team fairly quickly. Note that everyone is expected to think and contribute, regardless of who is on the keyboard.
  • We work on real stories, not fake examples.
  • Only one story is in progress at any time.
  • Have some fun with it.

“First time” rules

When we facilitate mobbing with a team for the first time, we insist on some extra rules. This is to ensure that they get the best first experience they can - for subsequent sessions, we’re willing to relax any of the rules at the teams request.

We request two full days for mobbing. We’ve repeatedly seen teams complete stories part way through their second day and we want them to hit this point. Less than two days might not give them enough time for this success. On the other side, more than two days is hard to schedule. Many teams aren’t willing to commit that much time with no meetings.

We want to start a new story at the beginning of the mobbing session. We’ve had cases where the mob attempted to pick up a story that had already been started and that was disasterous. We spent most of the time undoing the work that hadn’t been done with the techniques we were trying to teach. If the story you want to do has already been started, pick a different one. Facilitation notes

Occasionally, other non-driving team members may open their laptops to do research for the current story. Be careful if you allow this as many team members lack the dicipline to stay on topic and will drift into reading email, checking IM etc. It’s common for ScrumMasters and Product Owners to be reluctant to take a turn on the keyboard. We don’t force them to take a turn and yet we find that by the end of the second day, almost all of them have volunteered on their own. It’s important to enforce the switching of keyboards every 15 minutes. There will be a tendency for everyone to want to finish what they’re doing and that can stretch into hours if not watched.

Most teams will bring poorly written stories and/or acceptance criteria into the mobbing session. There will be a tendency to dive right into code but don’t allow this until the story, with acceptance criteria, has been fixed. It’s important to stress that without clear stories and acceptance criteria, we don’t really know what we’re supposed to be working on. Allow the team to decide when they want to take breaks although we ensure they don’t go more than 90 minutes without one. Mobbing, like pairing, can be draining and we need an explicit break.

While we do rotate the keyboard, it’s preferable to have the less experienced people on the keyboard more often. There’s often a tendency for an experienced person to just do the work instead of explaining their way through it. If there is one person who is clearly more experienced than everyone else, you may want to completely exclude that person from the rotation. It’s very easy for that one person to just do the work while on the keyboard without sharing what they know with the others.

The nature of mobbing requires everyone to be in the same room although it’s worth noting that we have done it with teams split across timezones. While we certainly don’t recommend this, we’ve proven that it is possible.

There is a tendency to want the team to debrief after their first experience with mobbing. I won’t ask them how they liked it unless they’re at least into their second day of mobbing. The reason is that the first day is often challenging, with people talking over each other and disagreeing. So if you asked how they felt, the feedback may be quite negative. By the second day of mobbing, those problems are usually gone and the team has stabilized. Asking for feedback at this point will usually result in positive comments. In fact, by the end of the second day it’s quite common for the team to ask if they can continue for a third day.

Common patterns

After using mob programming with hundreds of teams, we’ve seen distinct patterns emerge.

  • Almost everyone reports having had fun
  • Almost everyone learned something new
  • Almost everyone reports this having been a good use of their time, whether or not they wish to continue using this technique Most teams wish to continue using mob programming as an occassional technique - blocking off a day or two a sprint for this
  • A small handful of the teams we’ve worked with have decided to switch exclusively to a mob programming model so that this is the only way they work. It’s an interesting data point but not enough of a pattern yet
  • Teams that have mobbed are now more likely to do pair programming, even when they were reluctant to do it previously

More information

See also pair programming