QCon 2018 – Mob programming mini workshop

Main menu:

Topics

Recent Posts

Feeds

RSS Feed RSS - Posts

June 2018
M T W T F S S
« May   Jul »
 123
45678910
11121314151617
18192021222324
252627282930  

Past Posts

Java/Java EE

JDBC

Other

QCon 2018 – Mob programming mini workshop

June 28th, 2018 by Jeanne Boyarsky

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

Write a comment