Getting Started with Mob Programming


Mob programming is a software development approach where the whole team works on the same thing at the same time, in the same space, and at the same computer. Collaborating like this can have great benefits for everyone involved. Here, Woody Zuill details some practices his team uses to make this collaboration work for them.

Mob programming is a software development approach where the whole team works on the same thing at the same time, in the same space, and at the same computer. This is similar to pair programming, where two people collaborate and work at the same computer, but mob programming extends the collaboration to everyone on the team. It still uses a single computer for writing the code, but a projector shows everyone what’s on the screen.

On our mob programming team, everyone works together to do almost all the work a typical software development team tackles, such as defining stories, designing, coding, testing, deploying software, and working with the customers or internal partners and business people, whom we also consider to be team members. We strive to accentuate and amplify concepts such as face-to-face and side-by-side communication, team alignment, collaboration, whole team involvement, continuous code review, and the "self-organizing team" concept, to name a few.

How Did We Discover Mob Programming?

It all started about three and a half years ago. In an effort to increase our agile development skills and knowledge, we were spending three hours a week training and becoming more familiar with Extreme Programming techniques such as pair programming and test-driven development. We were making pretty good progress by studying and practicing in weekly Coding Dojos where the entire team joined together to work through simple code exercises. Studying together and frequently reflecting about how things were going provided a hidden benefit: We were learning how to work as a team. In our Coding Dojo we used one computer, one projector screen, one keyboard, and one mouse as the whole team worked together to solve one code problem at a time. To be able to study this way required that we follow a protocol of behavior and a few simple pair-programming techniques that made it easy for each team member to contribute and optimize the learning experience.

These newly minted teamwork skills and practices really paid off for us when one day we took on a fairly large project that had been put on hold a few months earlier. This project was relatively difficult and covered a broad spectrum of programming knowledge and skill that would require the best from everyone on the team. Where one person might be weak, someone else was strong. When none of us had the needed skills or knowledge, we wanted to learn and grow as quickly as possible.

We gathered together in a traditional meeting room and opened the project in our development environment using a projector so we could all review the code and other artifacts together. As we worked we naturally started passing the keyboard around, just as we had practiced in our Coding Dojos. The day wore on and we found we were getting a lot of work done. Each question we had was quickly answered by another team member, and there were few (if any) things that blocked us from making rapid progress.

At the end of that first day we all agreed to continue working together in the same way the next day. After a week of working this way, we found we were becoming very effective at turning out high-quality code, and we decided we wanted to find a permanent work area to continue working as a “mob.” We haven’t stopped since—and as I mentioned above, that was more than three years ago!

The Basic Principles and Practices

While we have few rules and follow a very dynamic approach to our daily work, we do have a basic principle and a few simple practices we use to make this collaboration work for us.

User Comments

1 comment
Clifford Berg's picture

Intresting. Reminds me of the IBM "whiteroom" approach, in which unit tests were completely replaced with whole group attempts to "prove the code correct". The bug rate for that process was as low as highly tested code.
But one concern: people's best ideas do not always come from group participation: epiphanies usually come in private, from quiet, from deep private focus. How do you allow for that?
In Susan Cain's book "Quiet: The Power Of Introverts In a World That Can't Stop Talking", she states, "There’s only one problem with Osborn’s breakthrough idea: group brainstorming doesn’t actually work...Studies have shown that performance gets worse as group size increases...The one exception to this is online brainstorming...This shouldn’t surprise us; as we’ve said, it was the curious power of electronic collaboration that contributed to the New Groupthink in the first place. What created Linux, or Wikipedia, if not a gigantic electronic brainstorming session?"

What are your thoughts on this?

- Cliff


October 2, 2014 - 11:45am

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.