Ensemble programming (aka “Mob Programming” or “Software Teaming”) 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.

“Entire team” means exactly that. Programmers, testers, product owners, scrum masters, specialists, etc.

Ensembles come out of work that Woody Zuill and his team pioneered at Hunter Industries and has been rapidly spreading across the industry. We’ve been using it in our practice since 2014 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.

How would I do this with my team?

There are many different variations on how to facilitate an ensemble session. We’ll talk first about how we do it and will then discuss some of the variations that we’ve seen.

When we do this for the first time with a team, we ask for two full days and will explain the rational for that further down. For now, keep in mind that we expect two days for all of these things to sink in.

There are three possible roles although we may only have two of them present in the room.

The driver is the person who has hands on keyboard. This is the person who is actually modifying the code, updating the documentation, testing the product.
The navigators are focused on more strategic thinking and are telling the driver how to approach the problem. Typically, the navigators are guiding the driver and not telling them specific details about how to write a loop or a function. Occasionally, we’ll get a driver who perhaps doesn’t know the language syntax or who isn’t familiar with the code and does need to be told those things, but that’s fairly rare. We normally assume that the driver knows how to drive and doesn’t need to be given instructions at that level.
The expert is the person who knows the system or the problem space better than anyone else. Often we don’t have a single clear expert and that’s fine. When we do have one, it’s important to call out because of the rules below.

We have only four hard rules and we’ll discuss each one.

The driver rotates frequently. Everyone gets a chance to be the driver.
The expert doesn’t get to drive. When the expert drives, nobody else learns.
All navigators are expected to contribute.
Whatever we’re working on is important.

Rule: The driver rotates frequently

We typically start the rotation at seven (7) minutes. When the timer goes off, the current driver steps away to become a navigator and someone different steps in to become the driver.

Most teams will push back on this and insist that this is far too short to actually get anything done. They’re wrong, and this is part of the magic of the technique. We have done successful rotations on as long a cycle as 15 minutes but we won’t go past that. The simple rule is that shorter is better. Some teams find that even 7 minutes is too long and they move to a shorter time.

If it takes too long to cycle back around to the first driver again, then people will start to disengage and the technique falls apart. Keep the rotation fast and you’ll get amazing results.

If this is the first time we’re doing an ensemble with a team, on the first day we only insist that the programmers take a turn as driver. By the second day, we start encouraging everyone else. We’ve had product owners and scrum masters as drivers and they’re great. You don’t need to have any background in coding to be the driver - the team will help you succeed.

Rule: The expert doesn’t get to drive

One of the fastest way to get people to disengage is to let the expert drive. Everyone will just sit back and let the expert do the work. For this reason, the expert (if we have one) is excluded from the driver role. Any knowledge they have must be shared with the other team members.

Rule: All navigators are expected to contribute

We often have people say “I’ll just watch” but that’s not the point. Everyone has something to contribute, even if it’s just questioning why we’re doing things in a certain way. This technique is about collaboration and actively working together, not some people watching others work.

Whatever we’re working on is important

We often hear “we know the perfect thing to do in an ensemble” and that’s almost always wrong. People will pick that item that’s been sitting on the backlog forever and we keep thinking “we should really do that” but it’s never been important enough. Don’t pick that one.

Pick the most valuable piece of work you could be doing. If the most important thing the team could be doing is fixing a production defect then do that. If the most important thing is performance tuning or retesting something then do that. When the work isn’t important then the team doesn’t care and the technique doesn’t work.

We should never be working on unimportant things anyway.

If this is the first time we’re doing an ensemble with a team then we ask for a piece of work that hasn’t been started yet. Picking up a half-finished piece of work can be challenging. If this is a team that’s already good at collaborating then this isn’t an issue anymore.

Why two full days?

Two days appears to be the “sweet spot”. It’s long enough to get the results we want and not so long that people are panicking about blocking the time. Almost nobody will agree to block off a week but two days seems reasonable.

With the approach we take above, we often get storming¹ in the first day. We’ll have people talking over each other and disagreements happening and if we asked the team what they thought at the end of the first day, they are almost always disliking it. Yet, by the end of the second day, almost every team we work with is asking if they can do it again. “Can we have a third day?”

By the second day, we’re starting to really collaborate. We’re starting to see results.

Across the hundreds of teams that we’ve done this with, we can probably count on one hand the number of teams that weren’t able to complete a story end to end by the end of the two days. In many cases, these are teams that have never completed a story in only two days before.

How does it work with a remote team?

Remote teams can work in an ensemble too. Certainly, many things are easier when we’re all in the same room but a significant number of teams have been doing this very successfully in a remote setting. See the mob.sh tool for an easy way to pass control between drivers. A team that is experienced with this can switch drivers in a matter of seconds.

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 occasional technique - blocking off a day or two a week for this.
Some teams we’ve worked with have decided to switch exclusively to a mob programming model so that this is the only way they work.
Teams that have mobbed are now more likely to do pair programming, even when they were reluctant to do it previously

Variations

Many facilitators will have only a single navigator and our understanding is that they do this primarily to avoid the storming that we get in the first day. In this model, we have one driver and one navigator and then everyone else. The driver only has to listen to one navigator instead of many and that allows them to stay more focused. If you can’t get two days then this might be something to consider.

Many facilitators will start with much shorter sessions. We want that first session to be longer (2 days) so that we are able to get through the storming and onto real successes for the team. If you’re using a shorter period then they may not get the immediate success and in our opinion, that’s a real shame.

More information

Interview with me on how I facilitate mobbing. We also get into some of the neuroscience that makes it work.
Woody Zuill and Kevin Meadows have written the excellent book Software Teaming: A Mob Programming, Whole-Team Approach, now in it’s second edition.

Storming is the least effective stage of the Tuckman Model. Ensemble programming is, in my experience, the fastest way to get a team out of storming and into the far more productive norming and performing stages. ↩