On the 7th of February, I attended a mob programming workshop which was conducted by Woody Zuill - the creator of mob programming.

The workshop was excellent as:

• Woody is incredibly passionate about mob programming.
• As he created it he has in-depth knowledge of it.
• He provided plenty of actionable examples and concepts.

Based on this workshop I have detailed my understanding in the following sections.

I go into what mobbing is, why it is good and how it works.

What

Mob programming is the idea of working on solving a problem as an entire team in one room as opposed to the traditional approaches of breaking the work apart and having each member of the team complete a task.

It is like pair programming but on steroids.

Mobbing is not a concept as much as it is a way of working together as a team in a cohesive way.

The key goals behind mob programming are:

• To spread the mental load of solving a problem across a team.
  • Done properly after a day of mob programming one will likely feel less drained than attempting to solve a problem by themselves.
  • I go into exactly how a mob works in the "how" section, spreading of the mental load makes much more sense after understanding the mechanics of mob programming.
• To spread knowledge across the team as everyone works on the problem together.
  • There is no key man dependency as the team as a whole should be able to adapt when members leave and re-enter the mob.

Terminology

Below is a table of the main terms used in a mob. These are described in more detail further in my post.

Team Composition

• Team Size: A mobbing team can vary in size from 3 people to much bigger
  • There have been mobs of 14 people
    • Where different people from the company were pulled in to more effectively and quickly complete a project.
  • A mobbing team with less than 3 people is a pair and loses the advantages of a mob.
• Team Skillset: A mobbing team consists of not only developers but also the other members of the team including testers, product owners and designers.
  • Even non-technical members should form part of the mob and act as drivers.
    • In the beginning they will need more detailed instruction but fairly quickly they will feel comfortable with the workflow.
    • Even someone just sitting and listening in is contributing by learning as they can provide additional input to the team.

Navigator/Driver Concept and How Observers Fit In

The idea for this comes from rally car racing where each car has one driver and an accompanying navigator.

It is the job of the driver to drive the car as fast as possible without killing himself, the navigator or anyone else.

The navigator, on the other hand, is responsible for planning the route they will use and feeding just enough information to the driver to not overload him (as to distract him) but still get him going in the correct direction.

From a mob programming perspective this is the exact sort of dynamics that the mob driver and mob navigator have:

• The navigator instructs the driver on what he needs to do
  • He can give very detailed instructions but should not have to if the driver is knowledgeable enough.
    • For example instead of saying draw a straight line then perpendicular to that draw another line and one more joining the 2 - he can simply say draw a triangle.
• The driver should do exactly as the navigator instructs and no more
  • He can ask for clarification if he is not sure.

The observers in the process are not allowed to talk. They simply observe and when it is their turn as the navigator they can give their comments and instructions to the driver.

• Depending on whether you are in the dojo phase (which is described in more detail below) observers can request to make a comment by getting the current navigator's permission and only one observer at a time.

Why

People's main complaints with mobbing are that it seems less effective as everyone is doing one thing together as opposed to everyone doing multiple things separately.

This may seem intuitive but in reality, it has been found that teams that adopt this actually find they work through more work more effectively.

• It has been so effective in some cases that other parts of companies have tried adopting it, for example, the marketing department mob marketing.
• It more effectively works through problems as answers are generally more readily available from within the team and do not require as much waiting for answers.
• The team can pick up errors together faster as there are multiple eyes on the problem, improving the quality of the product and reducing rework.
• The team can solve a problem and come up with more elegant solutions together than is often possible in isolation.

Many traditional work ceremonies can be forgone for example meetings happen less frequently in a mob as the team is on the same wavelength when working within a mob

• Meetings end up happening mainly with people outside of the mob.

How

Dojo

This is an exercise done by the team together to get them used to working in a mob. Generally, the dojo involves working on solving clear concrete problems like code katas.

The dojo is a phased approach to learning to mob where the earlier phases impose more restrictive rules. These rules are stripped away in each new phase until in the last phase the team is working as a mob. The process for a dojo is:

• The team sits in a circle facing a screen they can all see.
• All members of the team can and should form part of this exercise.
  • Even non-technical members should be able to drive.
    • In the beginning they will need more detailed instruction but fairly quickly they will feel comfortable with the workflow.
• The navigator stands.
• Every 4 minutes everyone lifts their hands and rotates to the next role.
  • Everyone gets a chance to be in all 3 roles: observe, navigate and drive.
• The different dojo phases get the team used to working in a mob.
• If at any stage we realise that no one was timing we rotate.
  • Generally in these situations the current rotation has gone on for too long anyway.

Phase 1

• There is one navigator.
  • The navigator stands.
• There is one driver.
  • The driver is only allowed to implement what the navigator tells them to.
  • The driver can ask clarifying questions.
• Everyone else is an observer and may not speak.
• Every 4 minutes these roles are rotated.
  • Teams can experiment with different rotation lengths.
  • Having mobbed before with a 30-minute rotation, 4 minutes is very sensible as it is just enough time to get stuff done but not enough for boredom to set in for the rest of team.
  • A tool can be used to assist with this but someone's phone timer is sufficient.
  • There is a tool called Mobster that has the list of people in the rotation:
    • It times for the duration.
    • When the duration is reached it disables the keyboard and displays who is up next.

Phase 2

• The team structure is the same and the process is the same.
• The difference is the following rules:
  • Observers may give suggestions but only if they put up their hands and get the navigator's permission to do so.

Phase 3

Phase 3 is when the team is fully implementing mobbing.

• This is identical to the previous phases with one key rule change:
  • Anyone can navigate.
  • There can only be one navigator at a time.
  • If someone wishes to switch they can put up their hand and ask to switch.
• If there is a differing of opinions for anything then the first opinion is done to completion before proceeding with the second one.
  • The team can decide after each of these which approach to use.

Office/Room Layout For a Mob

As the team will all be spending basically the entire day looking at one screen the following (sensible) recommendations were given:

• A large high-quality screen should be used for the whole team to look at.
  • Lower quality screens can cause eye strain and give people headaches.
• A large table should be placed parallel to the screen so that everyone is facing the screen directly.
  • If this is not the case people will likely get a sore neck after a day of having their heads tilted to the screen.
• A single machine, keyboard and mouse should be used.
• Ideally the team should have a dedicated meeting room so that they do not have to break their flow and move somewhere else.

Learning Sessions Daily

This is not required at all. But on the team Woody worked on he found this worked very well.

The idea behind this is that every day for the first hour the team would work towards learning something together.

In the process of mobbing concepts invariably come up that one or more members of the team do not understand. If the team were to address these during the mobbing session it can and would disrupt the flow of the team's work.

Instead when such a concept comes up:

• A ticket/post-it is made for the item.
• This is placed on to a type of learning backlog.
• The team decides what is most important to them as a whole and places that at the top of the backlog.
  • At the end of the day it is the team's responsibility to ensure that they read up or listen to a podcast on the topic at hand to ensure they are not going into the learning session blind.
• At the beginning of every day this top item is worked through by the team together.

If the team has no items to learn together they may do a dojo of some kata together instead.

Turn up the Good

The idea with this is that instead of fixing processes that are broken on the team, rather do more of what works really well.

For example, Woody spoke about how his team would do a daily retro at the end of every day.

Daily Retros

The retro is literally a 5-minute meeting that the team does together at the end of every working day. They reflect on what went well that day and what they can do better on the following day.

Team Accountability and Key Man Dependencies (hero complexes)

Everyone on the team works on everything together hence there is a sharing of knowledge and no key man dependencies.

If someone asks the team to solve something they work on it together. That way there is no one person approached for issues but rather the whole team.

Dealing with small and repetitive tasks

When working on a product small and repetitive tasks invariably pop up. These tasks may seem like a waste of time for the whole team to work on. But one approach is to complete these tasks together as a mob. But the team works to automate them as much as possible so that they do not have to work on them as much or at all in future.

Exiting and Entering the Mob

The mob team if following a proper process should easily be able to accommodate new people into the process and also make it easy for people to leave the mob and come back later.

Conclusion

I have worked in a mob before but there were always some key elements missing that resulted in the whole process not feeling 100%. In our case, it was the idea of the driver, navigator and silent observers with much shorter rotation times of 4 minutes as opposed to 30 minutes. When we used longer rotations it resulted in people getting bored and starting to look at their phones. The forced rotation also prevents one or two people from hogging the keyboard.

This workshop introduced these key concepts and gave actionable advice that we as a team definitely will work on together. The more I see and understand how mobbing works the more convinced I am that it is a very sensible and efficient way to work. We will try this together as a team and see how it goes.

The workshop covered an absolute fortune not all of which was covered in this post. I would highly recommend Woody's workshop to both technical as well as none-technical people as it is a wealth of useful information.