Title: Mob programming mini workshop: a whole team approach to the code
Speaker: Harold Shinsato

See the table of contents for more blog posts from the conference.

[I’ve heard this term before, but never experienced it. Curious to see how this goes!]

Concepts

• “All the brilliant people working on the same thing, the the same time, in the same space, on the same computer” – Woody Zuill
• Turn up the good.  A team would rotate who types to solve the problem.
• Far less bugs/tech debt
• More productive than working individually [that’s not the right comparison]
• Harold uses at Montano code school.
• Requires kindness, consideration and respect. Takes time to learn. Psychological safety and empathy are important.
• The team decides what to do and how to do it. Can’t force it. Just like forced pair programming doesn’t work.
• Important to go in with plan to experiment and see what works.
• Mobs of three good for coaching. Hunter uses mobs of 5-8.
• Rotation time varies. Can switch every 15 minutes or just have one driver.
• Mob worked with 50 people with language puzzles to learn/work through koans.
• Introverts need to check out regularly. And that is ok (for mobs larger than 5) because flow continues. A teammate catches up on what you miss.
• Gets people up to speed faster.

Roles

• Coach
• Driver – typist. Can’t have ideas. Just types. Smart input device.
• Navigator – everyone else. Helpful to start with one navigator so can practice not talking when know answer. Need others to practice leadership and develop expertise.

Problems with pairing

• Like a date. Awkward if doesn’t work out.
• Mobbing is safer because in a group. No one person is a single point of failure.
• Mobbing makes it easier to pair later. Harold uses mobbing before students pair

Strong pairing – where person at keyboard can’t make decisions

Demo – FizzBuzz in JavaScript

• Updated JavaScript to make tests pass
• Driver rotated on time or on passing tests. Time better for teaching as rotate faster. Did short iteration of 3 minutes to practice swapping.

Group Retrospective

• It was obvious to me what needed to be done before it was to the navigator. It felt awkward and timewasting to not say anything
• It felt really slow [probably because we were all new]
• As driver, I wanted to go faster than the navigator
• Hard to see vision. In a real mob, might draw out a plan

In practice

• Supposed to improve team in long run
• If someone knows most, they are primary navigator and turn into a leader – helping others.
• Get better at using tools
• Mobs of 8 good for teaching
• Hunter is most experienced of mobs. Switch every 15 minutes.
• Can speak at higher level if driver understands.

An audience member at Vanguard says her team does this once a day with eight developers.

My take

It would have been helpful to explain what mob programming is before asking who does it and for details. It was interesting to try. I would have liked seeing a video of a good mob doing it too. I can see how this is helpful for learning, but not actual tasks. Which is what people said about pairing at first. (or still do.) So I recognize that I don’t  have enough information/background to appreciate that.

After the session, I talked with an attendee who works at Vanguard. She says they do mobbing at two points:

• for an hour a day to accomplish a stretch goal (where it sounds like the whole team is learning together)
• organically – when one person ask another for help, who pulls in another and before long the whole team is involved