How to help a team to find their preferred mob programming rules?

5 minute read

A dysfunctional mob makes coaching impossible! So here is a workshop for team members to try and find the mob programming rules that work for them.

Drawing of a team doing mob programming, under a giant magnifying glass. There is also a banner that reads "Mob Programming Experiment NB#3". Running short mob programming experiments is a great way for team members to discover which mob programming rules work for them.

Have you got tips to put people at ease during mob programming sessions?

The same driver keeps driving for the entire session, the other participants look passive most of the time. (But I believe they are actually afraid to say something stupid!)

I would love to reduce the latent stress in the mob, but just saying “There is no stress” is visibly not enough!

In the past, I had some unhappy experiences with fast driver rotation on a topic that required much setup. This generated quite some frustration!

Introducing mob programming to coach teams is not easy!

Wouldn’t it be great if all mob programming coaching sessions were high-energy? If roles rotated smoothly? And the mob demonstrated the calm and natural collaboration of a well-oiled team?

A Code Retreat is a workshop where participants experiment many times with a topic. Let’s see how running a code retreat around mob programming helps members of a team to both:

  • Kick-off their mob programming habit
  • And discover how they want to mob.

We’ll see

  1. How to run a code retreat with Mob programming experiments
  2. Woody Zuill’s mobbing experiments
  3. More experiments!

How to run a code retreat with Mob programming experiments.

A code retreat typically lasts for half a day to a full day. It was first designed with programming in mind. You can learn more on codereatreat.org.

Here is how we run a code retreat of Mob programming experiments:

Before the event:

  1. Book half a day or a full day with all the team.
  2. Ask participants to imagine experiments of mob-programming rules, flavors, or styles. It could also be collaboration best practices that they would want to try.
  3. Make them vote on the experiments to rank what they want to try first.

During the event:

Photo of a path made of stairs that seems to be an endless loop! Similarly, a code retreat is a way to go over the same topic many times in different ways.

  1. Run a series of one-hour iterations:
    1. Take 5 minutes to make sure everyone understands the next mobbing experiment.
    2. Experiment with this flavor of mob programming for 40 minutes using a code kata or a piece of their code.
    3. Take 5 minutes to write down the pros and cons of this way of mobbing.
    4. Have a 10 minutes break.
    5. Repeat with the following experiment on the list.
  2. At the end of the day, help the team members run a whole-day retrospective. Make sure they agree on their mob programming rules.

It’s incredible how actually trying something stops dead-ends discussions between team members. In a few hours, we’ve seen groups go from dysfunctional muddles to calm and effective mobs!

💡 Don’t forget to slip in words about the bigger picture. The team can run code-retreats to experiment and make any collective decision!

You must be wondering what mob programming experiments might look like, so read on!

Woody Zuill’s mobbing experiments

I had the chance to attend a training by Woody Zuill about mob programming. He wanted to smoothly introduce strong-style mobbing. So he made us go through a kata using more and more elaborate mobbing styles:

Photo of children pairing at a computer. The driver is raising his hands, like I practiced with Woody Zuill to learn mob programming.

  1. First, we practiced round-robin the driver, navigator, and observers roles. We did not write any code, but we used super short cycles for a few minutes.
  2. Then we tried group programming with a driver, a single navigator, and observers. Everyone was silent except the navigator. We practiced for a few turns of 4 minutes on a code kata.
  3. Then observers were allowed to speak to the navigator after raising their hands.
  4. Finally, we practiced a “real” mob, with one driver, ‘polite’ navigators, and no observers.

The nice thing about learning to mob this way is that I understood what every variant adds to the previous one.

Three of Woody’s mob programming styles also make great experiments to run with teams:

  1. 1 Silent driver, 1 navigator who speaks, others are silent observers
  2. 1 Driver, 1 navigator, and civilized observers
  3. 1 Driver, All navigators

These experiments are a must-do for a team starting mob programming.

Surprisingly, many teams prefer option 2 to option 3! It looks like it makes space for thinking, and it leaves introverts a chance to speak up.

More experiments!

Photo of chemistry material, showing different test tubes with different colors, resulting from different experiments. The goal of the mob programming code retreat is to experiment different rules for mobbing so that the team can find their preferred way.

Here are other examples of the mob programming experiments:

Remote Mob Programming

If the team is mobbing remotely, they could test different mobbing tools. Or, if they don’t yet have the habit of turning their cameras on, they could give it a try and see what changes.

Giving Feedback

It’s a great idea to experiment with how to share feedback in the mob. For example:

  • Use the feedback-sandwich technique:
    • Start with positive,
    • Follow with constructive,
    • And end on a positive note again.
  • Or be inspired by Non-Violent Communication:
    • Start with your observations,
    • Then your feelings,
    • Follow with what your needs,
    • And end with a request.
  • How to interrupt to give feedback: raise a hand, change video background…

Photo of a sandwich. The upper and lower slices of bread are marked 'positive' while the middle is marked 'constructive'. This is a common technique to give feedback. It has its pros and cons, so better to give it a try in the mob and see if participants like it.

Many more!

Ideas for mobbing experiments are countless! For example, **if performance is crucial, a team could experiment with a dedicated role in the mob. **It could also explore mobbing in different contexts, like legacy or greenfield code bases.

As coaches, we can use this experimentation workshop for other aspects of collaboration. For example, we could run pair programming or reviews code retreats. This might even be a chance to nudge a team towards fewer reviews and more pairing and mobbing!

If you are looking for more disruptive and thought provoking mobbing experiments, check out this Twitter tread by Romeu Moura.

I went very quickly over these experiments. Tell me if you would like to read more about some of these!

Give it a try

Photo taken from behind of a women in a kayak on a lake surrounded by mountains. Running a code retreat of mobbing experiment is a way to explore and discover new ways of working.

Getting people to try something is already 90% of the change done!

Nothing beats experimentation when trying to find good ways to work together. Are you facing collaboration glitches when coaching with mob programming? Suggest this mobbing Code Retreat! The team will learn more in 4 hours than in many days of arguing.

What about you? Please share your mob programming best practices that we could experiment with!


Here are other articles to dig further:

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!

Comments