
Mob programming – The mob rules, OK? - theoengland
http://tooky.co.uk/the-mob-rules-ok/
======
zenogais
Did something like this at a previous job without giving it a name. It was
three of us around a single computer - we each took turns being the "typist"
with the others mostly watching and helping, but also using their computers to
lookup documentation or run a little ahead. Our job was to rebuild an existing
product from scratch on a very short timeline and with some experimental new
technologies none of us were familiar with. We programmed like this on a
television in a conference room for about 2-3 weeks as we bootstrapped the
program from nothing into a working core of functionality and abstracted away
from the experimental technologies into something more manageable that we
could use day-to-day. From here we split-off and worked in parallel and
brought in the rest of the team - who had been maintaining the old product in
the mean time.

The main benefits were that knowledge sharing was immediate as we all went
through the same learning process and helped build the same abstractions.
Problem solving was also incredibly quick. We eventually open-sourced the work
and it has been actively used by others for about 3 years now.

Overall mob programming was useful, but I think only with the following
constraints: \- Small mob size \- Limited time in "mob" mode \- High-level of
maturity and ability to work as a team among mob members

I think this could very easily turn into something nasty and unproductive with
a group of people who can't get along or aren't mature enough for this level
of cooperation and teamwork.

------
struppi
I have not had the chance yet to use mob programming on a real project. But I
have used it when teaching workshops and trainings. And it worked pretty well.

The first thing I noticed is that no-one tuned out. When I organized my
trainings so that participants do the exercises alone or in pairs, some would
just not do them. They might have too much problems to even get started. Or,
when pairing with a better developer, just let them do the work. In the mob,
paid attention everybody joined the discussion. [1]

Also, I think there was a better shared understanding of the examples and the
solutions after the mob programming. When working in pairs, I had to monitor
5-8 pairs in parallel and give them hints and explain stuff. With the mob, I
could concentrate on one screen and join the discussion _all the time_.

And: Others were helping me out. At one point, a participant said: "I don't
want to take the driver seat, I am no programmer, just a manager". Before I
could even say something, someone else from the audience said: "Come on, try
it. We tell you what to write, and after 10 minutes, we'll change again
anyway".

So, to recap: I really like mob programming for teaching. I think it could
also work well when a team wants to learn something new, has a hard design
session or wants to bring new team members up to speed. I even think it could
work during day-to-day work, but I have never tried that.

[1] Maybe I was just lucky and had a great group when we were duing mob
programming. But I doubt that.

------
pmilot
Mob programming sounds rather inefficient to me, but I'll freely admit that I
have never tried it myself. It might give good results if your team is
disciplined and talented, but can't that be said of all approaches to team
programming?

~~~
chipsy
I'm optimistic about it, though I admit that I haven't tried it. Code written
by a mob would have the benefit of receiving intensive review at the design
phase. There wouldn't be many opportunities for a mob project to spiral out
into duplicate functionality or mismatched modules. It's also potentially less
taxing than pairing because you'd get the chance to sit back and ponder
higher-level issues without constant prompting to fill in the next line. So
the overall result should be higher quality in the average case, with less
siloing of knowledge, and smoother daily output.

There are cases where you'd want the team to work more independently, but they
have to be weighed against communication costs. Those pile up quickly on any
team.

------
AngryOne
"We haven’t found a really good solution for a shared whiteboard yet."

May I suggest padlet?

[https://padlet.com/](https://padlet.com/) I discovered it about a 18 months
back when I was trying to find a way to leave notes for my wife while at work
behind a rather inconvenient firewall.

I believe it MAY work for what you're asking. I also rather enjoy the idea of
mob mentality! Thanks for the read.

Edited to fix typos and misplaced quotes.

------
jack9
No amount of testimonials will change my mind about this being a terrible
idea...at least not in that format (1 driver, x observers). I'd be willing to
try, 1 driver, 1 projector, X people with laptops. Break down project into
tasks, allow observers to implement tasks as driver works on task, share code
from/into project. That makes more sense.

------
RyanZAG
A 3.5 hour long meeting every day? This does not sounds like a good idea.

