Mob Programming Vocabulary | Pair Programming Exercises

1 / 5

"The team practices strong-style mobbing."

What is the defining rule of strong-style mob programming?

Strong-style (Llewellyn Falcone's rule): "For an idea to go from your head into the computer, it must go through someone else's hands."

What it prevents	What it forces
One person dominating by both thinking and typing	Ideas must be articulated clearly enough for another person to implement
Silent implementation without team awareness	Communication becomes mandatory, not optional

Key vocabulary: "typist role", "strong-style rule", "idea through someone else's hands", "ensemble programming".

2 / 5

"Let's rotate the typist."

In mob programming, what is the typist's role?

The typist role in mob programming differs fundamentally from the driver in pair programming:

Role	Decides what to code?	Right question to ask
Pair programming driver	Yes — executes their own and navigator's ideas	"Does this approach make sense?"
Mob typist	No — types what the mob dictates	"What should I type next?"

Typist rotation: frequent (every 5–10 minutes). Key vocabulary: "typist rotation", "typist as mechanism", "typist asks for guidance", "mob facilitation".

3 / 5

"The mob needs a facilitator."

What does the facilitator do in a mob programming session?

The facilitator is the process owner, not the product owner — they don't decide what the mob builds, they ensure the mob works well together:

Facilitator responsibility	Example action
Rotation management	Sets and enforces the rotation timer
Inclusive participation	"We haven't heard from Sarah yet — what do you think?"
Dominant voice management	"Let's hear from others before deciding"
Goal focus	"This refactoring is out of scope for today — let's log it and continue"

Key vocabulary: "session facilitation", "rotation timer", "inclusive participation", "dominant voice management".

4 / 5

At the start of a mob session, the team sets a "session goal".

Why is this important?

Without a session goal, mob sessions commonly drift into unfocused refactoring:

Session goal quality	Example
Good (clear, bounded)	"Complete checkout flow validation including all edge cases"
Poor (vague, unbounded)	"Work on the checkout module"

A clear session goal enables: scope boundary enforcement, a definition of done for the session, a productive mob retrospective at the end. Key vocabulary: "session goal", "definition of done for the session", "scope boundary", "time-boxed mob session".

5 / 5

"Let's have a quick mob retro."

What is a mob programming retrospective typically focused on?

A mob retrospective is a short, immediate process retrospective — distinct from code review:

Mob retro question	Focus area
"Was the rotation working?"	Process — energy, engagement
"Did everyone contribute?"	Collaboration — inclusion
"Was the goal clear enough?"	Focus — scope management
"Should we timebox smaller next time?"	Experimentation — continuous improvement

Key vocabulary: "mob retrospective", "process feedback", "experiment for next session", "blameless collaboration review".