Quality Note: This is a late night hackfest to get an idea out for a colleague.
(AKA - I rolled my face around on keyboard, and it'll show)

Also, sorry this is bumping my TDD LIKE YOU MEAN IT series. It'll resume next week.

Note: I know we're going to Ensemble Programming, but I'm gonna keep short-hand of Mobbing, so I'll stick with that throughout.

As a technical coach trying to expand mobbing in an enterprise, a lot of non-coders were interested in experiencing mobbing. Except they didn't want to code.
They wanted to understand mobbing without having to understand coding.
This is an absolutely reasonable request.

A huge lesson from the daily Kata exercises (and research into learning) is that if you're learning X while trying to learn Y, you'll learn neither. At least not well.
This lead me to work out something we can do that everyone already knows how to do, but do it as a mob. With rotations and all that good stuff.

I'll focus on one group I ran through a non-code mobbing exercise.
This group interested in understanding mobbing was the Agile Coaches cohort. They were the ones working closely with a lot of teams and had many of the initial conversations about mobbing in the origanization.
They understood the value of mobbing, but had never really done mobbing in a way that the Mobbing exercise was the learning.
Technically (hehehe) I was part of the cohort, but I was the Technical Coach, not an Agile Coach. Though I did my rable rousing about the correct agile... and then curtailed how much I roused the rable.

So - What did I do with the group to experience mobbing?
I honestly don't know if I came up with the idea, or I got it at a conference from those much more experienced coaching than I... I won't take credit for this; but I don't know who to give credit to.

We drew. Pictures. On the dry eraseboard.

Caveat: There are likely folks that this doesn't work for; but it did for the group of coaches and managers I was going to take through a mobbing exercise.

My tech coaching space had a mobile dry erase board and everything we needed. Yes my space; it was 6 Pair Programming stations. It was awesome. Not the story for now, but that where we went.

For any group like this - start at the beginning. We take Woody Zuill's words of how to participate in Mobbing

[W]e are committed to treating each other with kindness, consideration, and respect - Woody Zuill

There's a little pre-amble in a ... guide... that I can't find. So... Basically talking about the roles.
I used the same practice to start that I use with development teams. There are 3 roles.

Driver

This is the person drawing on the board. They will draw what the navigator tells them. The driver doesn't listen to any other mobbers.

Navigator

The is the person that's saying what they want to have drawn. Aside from the driver asking clarifying questions; the Navigator is the only person that should be talking. The navigator has final say of what to do, even when there's input from others.

The Mob

This is everyone else. They will be dilligently practicing SHUTTING THE FUCK UP.
OK, maybe some more appropriate language for different audiences; I had a good one, so I could out it that way.
The reality is, being quiet is hard. It's really hard. It's important to practice it.
We'd also never get an understanding of the Navigator role if we didn't enforce that the navigator is the only one talking.

The Facilitator

This is the person helping everyone else experience mobbing. No rules apply to them.
The facilitator has lots of roles; Which we will cover some shortly.

SET UP

The best reference I have on hand is this: https://www.mobprogrammingguidebook.com/images/mobprogrammingguidebook.pdf

I had another guide that I used for a lot of sessions... but can't find it. So... Sorry.

There needs to be a quick overview of the process with the participants, which is really just covering the roles and how to rotate.

Rotation: I use Navigator -> Driver -> Mob rotation. But the order isn't terribly important, just keep it consistent.

Pick something to draw. One of the exercises was a Haunted House as we were near Halloween.

Zero Round

Once you have a driver and navigator volunteers, you trick them and practice rotating. For mobs, getting rotation down is important. This is something I practice with developers learning to mob. Both in person and remote. Getting this portion smooth is very important for fluid mobbing.

Have a timer on your phone set to 2 seconds. And it's "OK, we're going to practice rotating".
Hit start and let the timer beep. "Hands up, Rotate". It's "silly" but the hands up is a really useful mental bit for rotating smoothly. If everyone does hands up, rotation tends to be really smooth. If not... there's normally a non-hands-up-er that slows it down.
Continue this until the driver and navigator are back in those positions. If it's taking more than 5 seconds to switch; go another round if it's not rotating smoothly.

First Round

For the drawing exercise, I like to set a 15 second timer. It's very short because I, as a facilitator, pause it a lot. The exercise is to learn mobbing. I'll pause the timer when someone is doing something I can use as a teachable moment for the group. And example of this is driver asking clarifying question, or the navigation speaking too detailed, or too broad.

One of the things I see new mobbers struggle with is how to navigate. Which is expected. It's hard to tell someone else what you want to do in a way they understand doing it.
If a navigator is going into too much detail,

"Draw a line at 45deg and 2 inches long. Draw a line starting at the top of that line and angle it downward at 45deg for 3 inches".

I will pause the timer when I hear that level of detail and let them finish. That kind of detail is PERFECT for one of my favorite facilitator questions:

What'd you want to accomplish?

Normally it's going to be something like, "Draw a roof". Which, "why not ask the driver to do that?". There's the concept of "communicate at the highest level your driver understands".
And example of this in drawing is the navigator asking, "Draw a gothic roof" ... which... If the driver doesn't know what that is, will need the lower level instructions of what lines to draw and how long. If we don't care and it's "draw a roof", perfect.

The other side is too broad or too big. "Draw a victorian house with a widows walk and wrap around porch". ... That's way too much at once.

ROTATE

I like to have the first round of rotations go inbetween "units". Whatever the navigator was trying to accomplish, I'll pause the timer to let them get it done. Nothing big, but we want to hold off on "pick up their idea" until everyone's gone through each role at least once.

Second Round

I'll keep the timer at 15 seconds, but pause it less often. Sometimes I'll pause it so I can intentionally interrupt in the middle of something being drawn.
When this happens, we want to use whatever the navigator does as a teachable moment. If they continue what the previous navigator was doing, great. Call it out as soon as they make that request to the driver. Use the moment to highlight following what's being done. Mobbing is a "Yes, and" process. We build on what others have done, and were doing.
If the navigator goes off and instead of finishing the window, says to start a chimney, we stop the driver and hightlight... the exact same thing.
We want to continue what the previous navigator did.

If the navigator says to "let's erase X", we want to stop that and again, "Yes, and".

Keep interrupting mid-unit during this round to help understand picking up what someone else has started.

Third Round

By now the drawing is probably getting mostly done. This is where we can introduce refactoring.
Pick something in the drawing and ask the navigator to refactor it. The navigator can seek input from the mobbers now. Not the driver, though. Easier to understand the roles if we keep some of the role boundaries in place.
The biggest thing to keep an eye on here is making sure the driver doesn't do anything unless it's directed by the navigtor. The driver only does what the navigator asks.

Quick Retro

Once the first drawing is "done"; quick retro. No boards or anything for this, just invite input. I suck at retro's, so I'll leave it to you to figure out how to do a <5 minute retro to have time to go again.

DRAW AGAIN

Mix up the order of the mob. Switch the timer to 25 seconds. This will let the navigator get some stuff accomplished, but have some interruptions.
It's also when we want to let the entire mob contribute ideas, when the navigator asks for input.
As a facilitator, you'll get to say one of my favorite facillitator phrases, "Who's navigating?" when a mobber contributes w/o the navigator asking.

I don't often see it in leadership groups running through one of these, but - as a facilitator, be aware of power dynamics and support/promote anyone on the lower end of that dynamic. Make sure their voice is heard and promoted.
If a C-Level and a team lead both give ideas, suggest using the team-leads idea and we can refactor the drawing later if it doesn't work out. This is something very important for any mobbing group. Again, most leadership groups are great at making themselves heard.
Same thing goes for being aware of someone dominating; and shut that down. Mobbing is all about "kindness, consideration, and respect" and as a facilitator, you get to make sure it is.

THE END

At the end... retro again. This should be a 15 minute retro to have some good discussion and followup about the experience and remaining questions.
I'm not great at retro's so I won't try to tell you how to run it.

Helpful Stuff

One helpful resource on what the 3 roles are supposed to do is: https://github.com/willemlarsen/mobprogrammingrpg
We only care about 3 roles
Navigator: https://github.com/willemlarsen/mobprogrammingrpg/blob/master/theNavigator.pdf
Driver: https://github.com/willemlarsen/mobprogrammingrpg/blob/master/theDriver.pdf
Mobber: https://github.com/willemlarsen/mobprogrammingrpg/blob/master/theMobber.pdf

We don't need to be playing the game to use these to understand the roles. It's the types of things each role should be looking to do.