I’m a lone wolf. I’ve been an independent software consultant my entire professional career. As such I am a team of one most of the time. Ironically, when COVID hit, instead of being driven into isolation, I became more connected with people. This is because I started the practice of mob programming regularly.
Unlike in pair programming where two developers are working on the same story together, in mob programming more than two developers work together on the same story. This may sound inefficient, but it turns out to be a highly effective and efficient way of building software.
Over the last decade and a half, I have shown thousands of professional software developers how to do pair programming and mob programming in person but when COVID hit it changed everything. I put my classes online and began facilitating remote mobbing sessions. What I found is that remote pairing and mobbing are powerful ways of working together.
There are many physical tasks that require more than one person. I recently moved to a new house and there’s no question that I needed two other movers to help me. My desk, my bookshelves, and my king-size bed are all “two-person jobs” to get upstairs in the new house. There are many intellectual challenges that are just as unwieldy as trying to maneuver a king-size mattress up a flight of stairs by yourself.
Pair programming and mob programming are not about taking turns at the computer. They are about bringing more than one mind to bear on the same problem at the same time. As Woody Zuill, the discoverer of mob programming says, “All the brilliant minds working on the same thing, at the same time, in the same space and on the same computer.”
Well, now that we work remotely, we could modify that to say, “…in the same (virtual) space…” In my experience, remote mobbing works just as well if not better than in-person mobbing. It’s different than in-person mobbing and requires special considerations but when done well, it can be a huge productivity and morale boost.
It’s easy for teams and their managers to dismiss mob programming as not worth it but consider these important advantages to mobbing over working solo.
* Mobbing is a fast way to propagate skills and practices across a team
* Mobbing gets everyone on the team on the same page with the code that is being built
* The code that is built by a mob is far more consistent, cleaner, and with far fewer defects than code that was built by a single developer
* Teams that mob need to attend far fewer meetings because, well, they are always together
Personally, I see a place for both pair programming and mob programming in most software development. I like to mob to propagate skills across a team, for learning within the team, and for helping the team remain a team even when we are working remotely. I like to pair when I have a complex feature to implement.
I typically like to mob anywhere from 2 to 4 hours a day. The same for pair programming. Pairing and mobbing our exhausting and while it’s a lot of fun, it can also be a major effort. I don’t have the expectation of doing these practices eight hours a day. If I can get a few good hours in each day along with all of my other responsibilities, then I feel good.
I found from experience that nearly everyone can immediately achieve true collaboration in pairing and mobbing by following one simple rule that my friend Llewelyn Falco defines as the basis for strong-style pairing and mobbing. Llewelyn says, “In order for an idea to go from your head into the computer, it must go through someone else’s hands.” In other words, if you get an idea don’t grab the keyboard and start typing. Instead say, “I have an idea, take the keyboard and type this.” This ensures that both people stay involved and engaged.
As soon as this happens, what I invariably see is that people fall into a flow state. They get on the same page and start really collaborating. They recognize that all the tools that they need are right in front of them so they stop talking about what could be and start trying stuff to see what works. And productivity skyrockets.
I was a proponent of pairing and mobbing before COVID but now that many teams work remotely, I find that these collaboration techniques are even more needed. They help teams stay on the same page and stay productive while sharing skills and knowledge. Teams that collaborate for at least an hour each day are far more productive and satisfied than teams that don’t, in my experience.
Pairing and mobbing require skills. We don’t just come upon these practices by accident. We must learn how to do them effectively. Unfortunately, I rarely see a course or a book on the subject. However, these practices are extremely valuable, and I can tell you, being someone who has witnessed how the top software development teams in the world build code, that many of them collaborate through pairing and mobbing.
These skills are just as important as knowing the keywords of a programming language. I find that having teams follow certain protocols during these practices can significantly boost collaboration and productivity. As a quick overview, here are some of my favorite mob programming protocols.
Pairing and mobbing involve collaboration skills that most of us were not exposed to and it often takes a while for us to learn them. Therefore, I like to introduce an initial constraint that I tend to relax when working with experienced mobs. That constraint is ‘one driver one navigator.” In other words, as we rotate through drivers in the mob–that is the person who is currently at the keyboard–we also rotate through navigators–that is the person who is talking.
Working in experienced mobs, the entire team can navigate the driver, but it often takes a while for the team to become sensitive enough so that every team member feels that they have a voice and can contribute. This usually takes something like 400 to 800 hours of mobbing together before a team gets to this level of trust and collaboration. Initially, we rotate navigators when we rotate drivers so that everyone is assured to have the opportunity to talk and express their opinions. Everyone also has the opportunity to be the driver or typist and listen to what the navigator is telling them. The biggest part of forming an effective mob is to find ways so that everyone on the team has a voice and is heard.
Another important aspect to make sure everyone remains engaged is to give everyone the opportunity to be at the keyboard at least every 20 minutes. I prefer to swap out drivers frequently, at least every 20 minutes but hopefully sooner during a natural break such as when we finished writing a test or making a test pass. When I’m pairing, I’ll often set a 20-minute timer so that if we miss these opportunities we have a hard stop when the timer goes off where we can swap roles.
When mobbing, I also like to make sure that everyone in the mob has the opportunity at the keyboard every 20 minutes or so. This rule defines the length of a turn. For example, if there are four people in the mob then each person would drive for five minutes. If there were seven people in the mob, then each person would drive for three minutes. The larger the mob the shorter each turn is.
Either way, it’s pretty much impossible to complete anything in three to five minutes and this is by design because it forces the next person who is navigating to pick up and follow the train of thought from the previous person. At this point, everyone either gets on the same page and starts down the road of hyper-productivity or they fall into chaos. We must be able to follow a train of thought together, building on other people’s work, and this next practice can help us with that.
Before we start the timer and begin coding a story, we have a discussion. We talk about the steps involved, first to write the test for the behavior we want to create, or if we already have written the test, we describe the steps involved in making the test pass. We do this as English comments that we will later replace with code. This allows everyone in the mob to see and agree on the basic steps for the code that we will be writing and once we all agree we can start the timer and begin coding. We use the English descriptions to help keep us on track so that at every step we know what we are doing.
Another simple practice that really helps keep the mob focused is callouts. Right before we start up the timer, we call out who is driving, who is navigating, and who is next. The driver simply says, “I’m David and I’m driving,” and the navigator says, “I’m Scott and I’m navigating,” and the person who is up next to drive says, “and I’m Bernstein, I am next.” This is a simple practice, but it assures that everyone in the mob is focused together and on task.
It’s easy for productivity to drop to zero when working online. Fumbling around with the mute button and other technical challenges can make working online difficult so it’s important for everybody to stay focused when working together. This naturally happens when we’re in the same room together and we must make an extra effort to do this remotely.
The goal of being the driver in the mob is to be in service to your navigator or navigators. You don’t get to think. You don’t get to have an opinion, in less asked. You simply do what your navigator tells you. For the time that you’re the driver, you are simply a typist. This makes being the driver the easiest role in the mob but it’s also an important one because the driver is the one who deals with the minutia of entering the details, freeing up the navigator to think at a higher level.
However, it’s easy as the driver to go on automatic and not recognize and learn from what is happening so Llewellyn in his mobs has been doing a driver recap before swapping roles. At the end of the turn, the driver pauses the timer and simply states what the navigator had them do and why. It sounds simple but this is hard to do. Having now developed this muscle over the course of several months I find it to be an invaluable practice.
So, what does the rest of the mob do when the driver and the navigator are doing their thing? Well, everyone’s paying attention to what’s being done but if only the navigator can speak, how does the rest of the team contribute? This is where the “wisdom of the mob” comes in. Chris Lucian, Willem Larson, and many others have described different roles that members of the mob can take. These roles help encourage collaboration and creative problem-solving.
Here’s a flavor of some of the roles: The Researcher finds ways of sharing relevant information. The Sponsor supports ideas from quieter people. The Automationist finds ways of reducing redundant work. The Anthropologist records a history of the team’s decisions and the reasons. The Nose looks for code smells and how to fix them. Dr. Feel Good calls out and praises when good things happen.
These mob roles help encourage the right kind of collaboration so when I see them happening, I like to give them a voice and point them out to the mob.
Perhaps the most amazing and valuable aspect of mob programming is something I don’t see a lot of managers talking about. As you probably know, unlike manufacturing or the construction of physical things, when we add more people to a software project it often has the effect of slowing it down rather than speeding it up. We call this “Brooks Law” after Frederick Brooks who wrote a book called The Mythical Man-Month. In his book, he describes that adding more developers to a software project that is late tends to make it even later. The same thing is true when we reorganize or remove members of a team. Any change to a team can disrupt its natural dynamic and flow.
But not so in a mob. When team members mob together, we can add new members to the mob or even remove members from the mob without affecting the mob’s productivity. This is huge. The only way I know to break Brooks Law is through mob programming. This alone should be a major benefit and reason to adopt mob programming on many teams. I consistently see teams that invest in learning how to mob correctly use it to transform how they do the work.
We are only human. We all have good days and bad days. When we code by ourselves, what ends up getting into the code is the level of awesomeness that we were experiencing when we wrote it. But when we work in a mob what ends up in the code is the best work from everyone. As a result, a mob can create cleaner code than any individual from the mob. This often translates into higher productivity from the team overall.
Mob programming is awesome but it’s one of those things that you must experience. It’s hard to describe. It’s counterintuitive to many software developers and managers. But the proof is in the pudding, as they say. Or in the putting. And putting software development into practice through mob programming can be a highly effective way of building software.
If you’d like to learn more then let’s talk. You can schedule a call with me here.