Mob programming is great stuff! We have found it to be the best way (so far) to teach technical skills to teams of programmers, and the best way for them to continue developing and teaching their skills well beyond our workshops.

Here are a set of tips that help us to make mobbing more successful in organizations:

Mobster

Mobster is a tool developed by Dillon Kearns to help teams manage to swap “drivers” during mob programming sessions. It also helps them remember to take disciplined breaks. A team can customize the timing and randomize the pattern of drivers if they like. It’s been a helpful tool for us.

7-Minute Timer

We find that there is a timing tradeoff to be made, especially when teams are new at mobbing.

If the drivers’ session is too long, then people not driving sometimes have trouble maintaining attention. After all, it might be over an hour before they are driving again. This should not be a problem since all the non-drivers are the ones actually programming, but turns out to be a problem for enough people.

Likewise, if the session is too short, drivers feel like they didn’t really contribute anything and the overhead time for switching partners feels like waste.

Some teams like 5 minutes, some like 15. We find that 7 minutes works out pretty well, and often is pretty close to the sweet spot for many teams.

One interesting variation was to take 60 minutes (as a session length), then subtract 10 minutes for our disciplined break, and divide the remainder by the number of people in the room. You can do a similar calculation and end up with driving sessions short enough that everyone gets a turn every hour. There is no reason you can’t plan your session lengths and breaks first, and subdivide the remainder.

Regular Breaks

Tools like Pomodoro and mobster help remind teams to take breaks, but sometimes team members are accustomed to having to always be at their desks so they feel guilty not programming during the course of a normal day.

We find that disciplined break-taking keeps us fresh all day. A few minutes here or there to check email, wander the halls, fill our water bottles and the like can be refreshing and leave room for new ideas to incubate. Sadly, a lot of people have been trained to think of programming like factory work, and want everyone to keep their noses to the grindstone for a full 8 hours a day – a system that doesn’t really work for knowledge workers, especially those in group settings.

We take breaks. It works.

No Running Away

In a mob, there is one “driver” at the keyboard, and the driver’s job is to do what the navigator(s) say. In a strict driver/navigator mob, there is one navigator and everyone else is an advisor.

Either way, the driver is not in charge. The driver’s job is to operate the machine only. The rest of the group decides what to type, what to move, what to delete. The driver executes the will of the team so that every idea “goes from one person’s brain through another person’s hands” (says Woody Zuill).

When the driver starts to execute their own vision, we call that “running away.” Nothing the driver types should be the driver’s idea, because that would leave one person programming while N people watch – clearly a wasteful practice.

We call out “no running away” when a driver starts to “run away” with the machine. It’s a reminder of the promise we have to observe proper mob programming and vet each others’ ideas as we work.

Find The Driver’s Level

When mobbing, some people are very familiar with programming, refactoring, testing, and navigating the IDE. Complex commands can be delivered in shorthand like “reorganize the imports,” “extract this to a field initialized in the constructor,” and “move this block to a function in class Z.”

Other drivers may have to be told specifically what hot keys to press (“press command-alt R”) or what text to type.

It’s important for the navigators to not direct an experienced driver as if she were a novice, or a novice as if she were expected to operate as an expert.

We tell drivers to lean back with arms crossed when they are overwhelmed or micromanaged, and likewise when the room is deliberating and not giving instructions. Then when the room takes notice, to ask for what they need from the room.

Sometimes a driver’s time will lapse without the driver entering anything into the computer. This is okay. Sometimes 7-15 minutes of thinking will help the team make a better decision, but seeing the driver with arms crossed is a sign that we need to get to a point of action soon.

Argue IN Code

Developers think in abstract ways about problems. It’s a super-power of programmers. We also have a tendency to have our own views and opinions, and to weight our values and practices differently and so we deliberate as a group. We do this quite a lot. It’s a good part of the process and ensures that our best ideas make it into the code.

However, sometimes we deliberate/argue about the abstract nature of the problem, and we have trouble relating to each other. We try to never argue abstracts for more than 5-10 minutes. The best way to avoid pointless, wasteful arguments it to get down to concrete examples.

This is why we “argue in code, not about code.” When we see non-abstract implementations, we usually either agree outright, or can come to agreement quickly. Concrete cases are usually simpler and more obvious. Sometimes when we “get down to brass tacks” we can see that we were arguing the wrong abstracts to begin with.

Marick says “this is a good place for an example.” We say that when mob programming, any time a discussion goes meta, stalls on abstracts, or lasts more than a few minutes.

Waste Snake

The “waste snake” is a mechanism I learned from Martine Devos. It is great for tracking the instances when some technical or organizational problem has caused team members to lose time (wait, start over, etc).

When people work solo, they tolerate delays and drudgery. After all, it’s one person and it’s only a few hours, it’s not worth undertaking a mission to eliminate the delay. Sometimes the individual wanders off and reads some web articles, or checks social media for a while, or switches to some other task. They’re not blocked overall, just on the one thing… they can increase the Work In Progress or take a break until the blockage clears. If it’s dull, repetitive work, they can just gut through it.

When a team is working together, then each outage or delay becomes obviously expensive. Waiting for someone to do dull, repetitive work is painful. Waiting until a server is back up, or a request is processed, or someone completes a pull request review? Impossibly painful. The secret? This has always been N people waiting for X hours per week, but with the people split up nobody noticed it. Now it’s too obvious.

You record delays and drudgery on the waste snake. When time allows, or when you get fed up, some of the people split off and go attack the problem. The resulting fix saves everyone time. As a result the whole team (and sometimes the whole org) becomes more efficient.

Learnings Board

A similar feature to the Waste Snake, where we record delays, we keep a Learnings Board, where we record each important thing we learn, or each thing we learn how to do.

It’s common that a mob will discover a technique that saves each person several minutes a day, or several hours a week. This goes on the learnings board.

Sometimes the team learns something about the domain that would otherwise have resulted in building the wrong product. This goes on the learnings board.

Other times, the team learns something about their technical stack (language, libraries, etc) that makes them more proficient, efficient, or effective. This goes up on the board.

The learnings from the learning board are celebrated and shared.

Promise Debt

One more Big Visible Display we like to use is a Promise Debt board. Any time the team comes across a task that they defer or a promise that they need to keep, they list it on the Promise Debt board. By the end of the day, they intend to “pay down” the promise debt by keeping promises and completing deferred work.

Invite the Experts

When the team is stuck (see “waste snake” above) one of the best ways to solve a problem is to invite some outside experts from other teams or organizational structures to join the mob for a little while. The experts will become advisors who help navigate the driver.

I’ve seen teams stuck for ½ a day invite in an expert and be doing productive work within an hour.

Of course the things we learn from the expert goes to the Learnings Board.

Invite the Boss

A mob programming team should invite the boss. Or the grandboss. Or the great-grandboss. Maybe the CFO or CIO. Certainly the director of software development. Maybe the product management people from the other floor of the other building. Sales? Customer support?

Often inviting people who don’t participate in the team’s daily work, and possibly don’t even understand it, will result in new appreciation and empathy between the teams and the other business units or levels.

I’ve only seen good come from this so far. It’s a strategy worth pursuing.

Credits

As much as I would have liked these ideas to have been all from my own imagination and experience, they are not. I received much direct help from Mike Rieser, Anthony Sciamanna, Nick Goede, Mike Rizzi, and Bill Wake … and possibly others whose names I didn’t record at the time. And, of course, the influence of many in the mobprogramming.org world.