Mob programming and shared everything

Mob programming is a technique we use extensively for sharing knowledge in the team, improving developer skills and increasing team cohesion. These might not be the primary goals of your business, but they probably contribute much more than you realise to achieving your goals. In this article, we share the techniques we have developed to make Mob programming feasible, fun and effective.

“Shared everything”

In a recent project, we introduced mob programming as part of our goal to share everything inside our team. We wanted to have all developers on the same level, rather than having titles, categorisations and specialisations. As a result of consistently applying a “shared everything” mindset, our team’s “bus factor” approached the team size.

Bus factor?

– Image by Lai Man Nung - unsplash

In any team, there are individuals who are the sole possessors of specific knowledge, knowledge which is essential to the team’s performance and the outcomes. If these people were to suddenly leave the team, the team would suffer.

The bus factor of a team is the number of team members that would need to be “hit by a bus” before the team would end up in serious trouble.

So the bus factor indicates how healthy your team is regarding knowledge transfer and skill sharing. A high bus factor indicates healthy knowledge sharing and a healthy team.

How did we apply mob programming and “shared everything”?

Mob programming – An adventure

– Remote mob programming session – Screenshot by the authors

During the project in question, we were lucky enough to use DDD (Domain Driven Design), TDD (Test Driven Development), and more importantly mob programming techniques.

Mob programming in a nutshell: You have one computer and three or more developers. One is typing (driver), one or the rest of the developers lead the driver and give commands (navigator-s). The whole team is working on the same issue at the same time. See the different mob programming modes in the experiment section.

Initially we had a bumpy start. Mob programming felt completely different to the software development we were used to. A feeling that we might not be moving fast enough was repeatedly mentioned in retrospectives, and there was the frustration of not being able to take the keyboard and control. We tried it, abandoned it, restarted, and stopped again.

In the beginning, we experimented a lot and were inspired by the Guide from Maaret Pyhäjärvi .

We started to see how knowledge was being transferred to every team member and code quality seemed to be increasing.

Nevertheless, the challenges continued. Just when we were about to give up the idea for good, we had a great mob programming workshop with Woody Zuill . This helped us to see how the technique allowed us to develop as people and as a team, and we were enthusiastic again! Among the many ideas we picked up from Woody was the practice of a daily retrospective. Generally we did this at about 4pm and tried to keep it to 5 minutes. In the daily retro everyone said something which went positive during the day. To get used to it, we needed to set up an alarm.

We needed to focus on remote mob programming, because the team members were spread over different locations. Here we got inspired by a remote mob programming guide from Simon Harrer, Jochen Christ, and Martin Huber. We needed to establish a few rules …

Some “shared everything” rules

• Camera always on
  
  

  – Image by Aksa2011, pixabay

  Since the team was spread over several locations, it was important for us to define the “Camera always on” rule. That helped that all team members felt like first-class citizens. It gives you a better ‘we’ feeling, especially for the remote members. Additionally, it promotes a better understanding in discussions and meetings, because you will get the gestures of the speaking person. Which brings us to the next rule…

• 30-second rule
  
  

  – Image by Aron Visuals, unsplash

  If a person speaks for more than 30 seconds off-camera, the meeting must be interrupted in order to force corrections.
  Since every one of us in our primary project office had their own notebook with a camera, most of the time everyone was on camera by default. However, typically stakeholders would visit us for meetings. In order to enforce our “shared everything” philosophy, everyone needed to participate in these meetings on equal footing. It was critical to adjust our setup so that all the guests in the room could clearly be seen by the remote members/participants. Whether for catching body language or simply for being aware of who exactly was speaking, this rule makes a difference like night and day. So, the extra persons were distributed to the existing notebooks (cameras), before the meeting started. The stakeholders were extremely co-operative.

• 10-minute rule
  
  

  – Image by Clem Onojeghuo, unsplash

  If a remote participant doesn’t say anything for 10 minutes, stop the meeting and ask them to say something or summarise the last minutes. Sure, that is a hard rule, but for us it was important that everyone understood the matter of the meetings and kept the knowledge spread. If someone doesn’t talk for a while, it’s usually an indicator that they have lost track of what is going on.

• Do you need a break? Take one.
  
  

  – Image by Alex, unsplash

  Mob programming needs high attention and focus, and learning is tiring. Everyone in the team should be allowed to take a break whenever it is needed. The positive thing while doing mob programming is that this person will get back into the flow quickly.
  We tried various break techniques, and generally settled on the “individual breaks” technique. We generally synchronised lunch, but otherwise there were no agreed breaks. Any person could take a short break whenever they felt it was necessary. When they came back we simply put them on the end of the list. This avoided discussion and organisation. And the person could get in again easily.

For business meetings of course, you need to take breaks together. Here we established another rule – the “45-minute rule”, which basically meant a forced break every 45 minutes. Meetings are quite stressful for remote participants who are not speaking their native language. This helps them to stay tuned in.

The rules above helped us a lot while doing mob programming. And mob programming helped us a lot to spread all the knowledge to every single team member. So, everyone on this team knows every small corner of our application and was able to work on every part of it.

Experiments for the win

As we mentioned earlier, we did a lot of experiments. Experiments are fun. So, for example, we tried to do mob programming in three different ways which we learned as “Dojos” from Woody Zuill during his workshop. We called them strict, soft, and freestyle.

• Strict
  
  The strictest implementation of the driver-navigator pattern. Only the navigator is allowed to speak, others simply watch. Literally, they may not speak, even to answer questions.This very quickly becomes frustrating for the mob as they see the navigator struggling but are not allowed to give them any answers. Surprisingly, this can create great benefits. The navigator learns to think out loud so that the next navigator can easily take over. Asking the mob questions (which go unanswered) is a surprisingly effective method of communication.The mob learns patience, and the vital art of letting someone else have a go; trying someone else’s ideas out. Once you learn to handle the frustration, you find that this is the most peaceful technique of all. No discussion, no arguments. Just coding and trying to understand each other.

• Soft
  
  This is similar to the strict technique, but the mob is allowed to speak when requested by the navigator. They can answer questions and also raise their hands and wait until they are asked to speak. This removes some of the seeming stupidity of the strict technique when you watch a teammate flounder. However, if you are not careful, this technique can degrade into long discussions and “freestyle”.

• Freestyle
  
  In freestyle mode there is one driver and the rest of the team members are navigators. Everyone is free to give a command, mention an idea, or start a discussion. We found that in this mode it was important to apply techniques to reduce discussion. One such technique is just accepting the idea of a colleague and trying it out to prove it good or bad, instead of discussing it to death. Often the result is surprising!

We think we ended up in the soft mode most often – a good compromise between other techniques. Freestyle felt like a natural thing to do a bit every day too. But, we found that we had to reserve a time slot (maximum of 1 hour) for doing the strict mode because we valued this training in solution finding and patience, but one doesn’t just accidentally fall into doing something that feels so unnatural.

We also experimented with the mob programming time. So, we tried to set the timer to a very low (2-3 minutes), medium (5-12 minutes), and high (15-25 minutes) time. And then we started to mob for 1 to 2 rounds. We figured out that a timer set too high will cause followers to lose their focus. Also, too low times are bad because you start, think about something, start a small discussion and boom …. the time is over. At least, we stick to 6-8 minutes for a driving round. It was enough time for us to get something done, but also to discuss a little about an idea.

As a remote team, we also had to factor in the overhead of switching (pushing to a dedicated Git branch, switching screen sharing). We managed to reduce this to 30 seconds when we were disciplined, but no further. So with a timer of less than about 6 minutes, this became a significant aspect.

What about the mob programming patterns

Another thing we tried are different ways of driver-navigator patterns. Many teams are stuck on the navigator-driver-mob pattern. We tried every possible variation:

• Navigator-driver-mob
  
  The navigator becomes the driver, the driver joins the mob, and the next out of the mob becomes the navigator.

• Driver-navigator-mob
  
  The driver becomes the navigator, the navigator joins the mob, and the next out of the mob becomes the driver.

• Driver-mob-navigator-mob
  
  The driver and the navigator join the mob and the next two of the mob become the driver and the navigator.

Driver-navigator-mob became our default order, because:

• If someone lost touch with what was going on, they had a better chance to mentally get back into it as a driver before becoming navigator. 
• The changeover friction is reduced when the driver comes from the mob. They can ensure they have the right programs and classes open 30 seconds before changeover, which isn’t practical when they’re trying to navigate.

However, at various times we found the other patterns to be interesting and helpful. Did we mention it before? We loved to experiment.

Psychological safety

Research has shown that psychological safety is a strong predictor of team performance. This is basically feeling comfortable to say what you think and be who you are without embarrassment or fear of repercussions. Collaborating together so closely helped us bond as people. There was rarely such a thing as “someone else’s code”, and everyone knew and was comfortable with everyone else’s capabilities and personal circumstances.

We managed to meet and work together in person a number of times – something which is very beneficial. Meet live, have a beer together in the evening, meet the family of your colleague – these are things which strengthen a team into a unit.

The irony of shared everything and bus factor

Using the mob programming approach as part of a “shared everything” mindset can be very beneficial. As the project went on, we noticed that our bus factor had approached our team size. In other words, you would basically need to remove the entire team for the knowledge and skills to be lost from the project. This is quite a phenomenal result.

We also discovered a high satisfaction spread through the team. Everyone was passionate about doing the experiments and working with each other. No-one feared to say “I didn’t get this”, “could we change this?” Or, “we should try this”.

– Image by Ryan Tang, unsplash

High bus factor protects the team in the case that people leave it. Yet the irony of this is, when a “shared everything” team is established, no-one wants to leave. We had no fluctuation in our team during that project.

Despite the really interesting technologies and co-operative customer involved in the project, at the end of the project one team member summed up the team feeling by saying “I’m really sad that this project is ending. Not really because of the project work, but because of losing the team”.