Whole Team
We bring the insights of the whole team to bear.
In the early days of Extreme Programming, when pair programming first became popular, people used to mock it. “If pairing is good, why not triple!” they laughed. “Or just put the whole team in front of one computer!”
They were trying to put down XP, but the Agile way is to experiment, learn, and improve. Rather than assume something won’t work, we try an experiment. Some experiments work; some don’t. Either way, we share what we learn.
That’s what happened with mob programming. Woody Zuill had a group teaching technique he used for coding dojos. His team at Hunter Industries was in a bind. They decided to try Woody’s group technique on real-world work and put the whole team in front of one computer.
It worked, and worked well. Woody and the team shared what they learned. And now mob programming is used around the world.
In some parts of the world, the term “mob programming” has unpleasant connotations, so people call it ensemble programming instead. Woody Zuill’s original name for it was “Whole Team programming.” But, he says, “I have always said, I don’t care what it’s called. Learning to work well as a team is worthwhile and I invite people to call it what they will.”3
Mob programming is a variant of pair programming. Like pairing, it has a driver, who codes, and navigators, who provide direction. Unlike pairing, the whole team is present. While one person drives, the rest of the team navigates.
You’re welcome to try any approach to mobbing that you like. As Woody Zuill said, “There are no rules except the general guideline of ‘Let’s figure out how to turn up our ability to collaborate well.’”4 Experiment and find what works for you.
To get started, try Woody Zuill’s approach. It starts with the whole team present and ready to participate. Some people, such as on-site customers, may not be focused on the programming specifically, but they’re available to answer questions and they’re working on the same stories the programmers are.
On top of that base, layer on Llewellyn Falco’s strong-style pairing: all ideas must pass through somebody else’s fingers. [Falco2014] When it’s your turn to drive, your job is to act as a very clever input device. How clever, exactly, depends on your familiarity with the code and the editor. In some cases, a navigator might say, “Now handle error cases,” and the driver will test-drive four tests and the accompanying production code without further prompting. In other cases, a navigator might say, “Now extract the method,” and the driver will have to ask what to type. Customize the level of detail to each driver’s experience with the code and tools.
Finally, add a timer. Seven minutes is a good starting point. When the timer goes off, the driver stops. Another person takes over and work continues right where the previous driver left off. Rotate through everybody who’s interested in programming.
Mob programming works because it’s “easy mode” for collaboration. So much of Agile centers around communication and collaboration. It’s the secret sauce that makes Agile more effective than other approaches. And mobbing makes a lot of the Agile collaboration practices irrelevant. They’re simply not needed when you mob.
Stand-up meetings? Gone. Collective code ownership? Automatic. Team room? A no-brainer. Task planning? Still useful, but kind of unnecessary.
When I first heard about mobbing, I poo-poo’d it. “I get the same benefits from having a cross-functional team, a team room, pairing, frequent pair switching, and good collaboration,” I said. And I was right. Mobbing doesn’t get you anything you don’t already get on a good team. But it’s so easy. Getting people to pair and collaborate well is hard. Mobbing? It’s practically automatic.
If you have a physical team room, it’s pretty easy to set up a place for mobbing. You need a projector or big-screen TV (or several), tables for people to sit at, and a development workstation. Make sure everybody can sit comfortably, has access to laptops and whiteboards (for looking stuff up and discussing ideas), and has enough room to switch drivers easily. Some teams provide a mobbing station as well as pairing stations so people can switch back and forth as desired.
If your team is remote, set up a videoconference and have the driver share their screen. When it’s time to switch drivers, the previous driver pushes their code to a temporary branch and the next driver pulls it. A script such as the one found at https://mob.sh can help with this process. You might find that you need to set a longer timer—perhaps 10 minutes instead of 7—to reduce the amount of switching needed.
Mobbing is fun and easy, but it can still be tiring to work with the whole team day-in and day-out. Here are some things to consider:
Pay attention to the interactions between team members and make sure everybody’s voices are being heard. Establish working agreements, make it safe for people to express disagreement and concerns, and pay attention to team dynamics. If there’s someone who tends to dominate, remind them to let others speak; if there’s someone who has trouble speaking up, ask for their opinion.
When you first start mobbing, it’s worth spending a few minutes at the end of each day for a very short retrospective. Focus on what worked well and how to do more of it. Woody Zuill calls this “turn up the good.”
Mobbing isn’t supposed to wear you out, but it can be overwhelming to be constantly surrounded by the whole team. Take care of yourself. You don’t need to be “on” at every moment.
One of the advantages of mobbing is that it’s not dependent on any one person. People can drop in and out as needed. If you need a coffee break, or just want to clear your head, step away. Similarly, if you need to check your email or make a phone call, you can do that. The mob will continue on without you. You don’t have to align your work hours, either.
All changes to the production code go through the driver, but you can still use your computer when you aren’t driving. If you need to look up an API call, or have a side discussion about a design idea at the whiteboard, or create a spike solution, you can do that.
When you start mobbing, your team might have so many people shouting ideas that the driver has trouble understanding what to do. In this case, rather than having the whole team act as navigators, you can appoint one person to be navigator. This role rotates just like the driver role does. (I like to have the driver become the next navigator.) Their job is to condense the ideas of the mob into specific directions for the navigator. The driver has to listen to only the navigator, not the whole mob.
Everybody in the mob can be a driver, even people who don’t know how to program. This can be an exciting opportunity for non-programmers to develop new skills. They may not become experts, but they’ll learn enough to contribute, and learning to drive could improve their ability to collaborate with programmers.
Remember to guide your driver at the level they’re capable of following. For non-programmers, this may require providing direction at the level of specific keyboard shortcuts, menu items, and mouse clicks, at first.
But nobody is required to be a driver. Some people on the team may find that their time is better spent helping the mob in other ways. A tester and a domain expert might have a side conversation about customer examples related to the current story. A product manager may step out to conduct an interview with an important stakeholder. An interaction designer may work on user personas.
As with anything else, experiment with varying people’s level of involvement to find what works best for your team. But start by trying more involvement, rather than less. People often underestimate the power of working as a team. That conversation about customer examples, or stakeholder interview, or user persona work could be something that the mob learns from doing together.
You don’t have to choose between pairing or mobbing. (Although I do recommend doing one or the other for all code you have to maintain.) You can mob part-time and pair the rest of the time. Or you can form a “mini-mob” of three or four people while the rest of the team pairs.
If you don’t mob full-time, be sure to keep other team coordination mechanisms, such as the task board and stand-up meetings, at least to start. The mobbing sessions may allow you to keep in sync without them, but make sure that’s true before removing them.
Is mobbing really more effective than working alone or in pairs?
For new teams, almost certainly. Teams’ effectiveness depends on how well they know the code and one another, and mobbing excels at this sort of learning. This is why I recommend that teams start with mobbing. (See “Your First Week”.)
For established teams, in my experience, pairing is more effective than working alone. Is mobbing even more effective than pairing? For teams with a good team room and great collaboration, maybe not. For other teams, it probably is. There are too many variables to say for sure, so try it and find out.
We’re having trouble remembering to switch drivers. What should we do?
If people are ignoring your timer, try using a tool such as Mobster (available at http://mobster.cc). When the time is up, it blanks the screen so the driver has to stop.
The whole team directs its entire effort toward one story at a time, finishing work with minimal delays and wait time.
The team collaborates well and enjoys working together.
Internal quality improves.
When a tough problem arises, the mob solves it while the driver continues moving forward.
Decisions are made quickly and effectively.
“All the brilliant minds, in the same place, at the same time, working on the same thing.” That’s the core idea of mob programming. Beyond that, the details are up to you. Start with the basic structure described here, then think about something to improve every day.
If mobbing isn’t a good fit, the best alternative is pair programming. Pairing doesn’t have the same automatic collaboration that mobbing does, so you’ll need to put more effort into collective ownership, task planning, and stand-up meetings.
Woody Zuill and Kevin Meadows’ Mob Programming: A Whole Team Approach [Zuill2021] is an in-depth look at the how’s and why’s of mobbing.
3 Quoted from a conversation with Woody Zuill on Twitter.
4 Another excerpt of the Twitter conversation with Woody Zuill.