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. 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.

• Principle: Treat each other with kindness, consideration, and respect.

Because we work closely together throughout the day, we are constantly communicating, and we must be able to express ideas, discuss problems, explore possible solutions, and share thoughts all day long. To make it possible to sustain this high level of communication, we have adopted the principle to always treat each other with kindness, consideration, and respect. While this seems straightforward, we feel that expressly acknowledging the importance of this principle provides a foundation for our daily interactions.

• Practice: Driver/navigator pair programming adapted to work with the whole team

We use a driver/navigator pattern we adapted from Llewellyn Falco’s strong pair-programming style. The basic rule is: “For an idea to go from your head into the computer, it must go through someone else’s hands.” Following this rule requires that we get good at communicating our ideas and ensures that everyone has a chance to discuss and scrutinize everything we do.

There are two roles using this pattern: the driver and the navigator. The driver sits at the keyboard and types in the code. The navigators express and discuss the idea to be coded and guide the driver in creating the code. This means the driver has a much more mechanical job than when coding solo. The driver listens to the navigators and must trust them because he is focused on the typing and coding. The navigators are expressing their ideas to the driver in a slow, metered approach so the driver only has to focus on the next thing to type at any given time.

As we discuss and work out the possibilities, both verbally and at the whiteboard, everyone is gaining a full understanding of the idea. This creates a sort of collective intelligence from the navigators and the team as a whole. We generally speak at the highest level of abstraction that the driver (and the rest of the team) is able to digest at the moment. Sometimes this can be at a very high level when the driver understands the concept to be coded and can proceed without detailed instructions. It can also be at a very detailed level if necessary—even at the level of keystroke instructions when needed. This will change from person to person and idea to idea.

For example, we were working on a feature where a business user could view a list of open shipments for a customer in our system. Dexter was the driver. He’s an accomplished programmer and was very familiar with the project we were tackling. The navigators discussed the feature for a few minutes and decided we would need a new web page to display the data and a query to retrieve the basic data. After Dexter asked a few questions, he had a good idea of the coding required to make it happen, so he simply started coding it. As it was clear that he understood the need and was making good progress, the navigators moved on to start discussing the next aspects of the story.

In another case, we had a complex report to create that required some complicated SQL queries. Even after extensive whiteboarding, the exact path was not clear and looked like it would require a great deal of trial and error. This report ended up taking several hours of work, so everyone had at least one turn at the keyboard. Because not every team member was strong in coding SQL queries, when each member took a turn at the keyboard, the navigators’ instructions would change based on the skills of the driver and the experiment we were trying at the time. Some could work with little help, and for others we would help at a very detailed level, such as calling out the SQL keywords or field names needed.

• Practice: Timed Rotation

We use a timer and a randomized rotation pattern. Every morning we create a new rotation list, and each team member works at the keyboard as the driver for a short period of time, typically ten to fifteen minutes, in turn. The driver hands the keyboard off to the next driver when his turn ends and rejoins the navigators. We don’t require that everyone take the driver role; it is everyone’s choice whether to do so.

• Practice: Whole Team

Our approach follows the Extreme Programming practice of “whole team,” where every contributor to the project is an integral part of the whole team. For example, testing is done by the team and in coordination with the business partners in our company who will be using the software—that is, the testing is done as a team effort. The business people (product owners, end-users, expert users, etc.) join our team for any testing that needs to be done, and we work closely with them as team members. Two of our team members have QA backgrounds, and two of us have managed testing of software as well. This is the idea of a real cross-functional team. We have all the skills we typically need for almost everything we do, including coding, designing, database, testing, and documentation. When we don’t have the skills we need within the team, we find someone who does and invite him to work with us to accomplish the needed work.

• Practice: Reflect, Tune, and Adjust Frequently

We follow the agile principle “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” We have taken this to heart and found it brings a great deal of value to us. We frequently evaluate what is working for us, what problems we might be having, and how we can improve on things. An important part of the principle is to “tune and adjust.” By simply paying attention and then tuning and adjusting, we have been able to choose actions that have led to tremendous improvements for us.

Turn Up the Good

This is the real story of mob programming: We noticed that working together was giving us great results and simply decided to do more of it. This comes from Kent Beck, creator of Extreme Programming: “When I first articulated XP, I had the mental image of knobs on a control board. Each knob was a practice that, from experience, I knew worked well. I would turn all the knobs up to 10 and see what happened.”

Our main takeaway was that if we are sure to regularly reflect, tune, and adjust, good things will happen. This is what made it possible for my team to discover mob programming and many other great things, and I am certain it will make it possible for you to discover great things for your team.