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