Mob programming – The mob rules, OK?

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.

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.

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?

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

May I suggest padlet?

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.

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.

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