Sticky mob programming

This is an excerpt from and my contribution to the experience reports section of Mob Programming - A Whole Team Approach by Woody Zuill and Kevin Meadows. If you want to start mob programming, but don't quite know how, I can highly recommend getting the book!

In 2015 I fulfilled a promise I had made myself; I went on a software journeyman tour.

The concept was simple. I would spend a week at a company with a team, working on whatever the team was working on, blog about it, and then move on to the next company. Money was not changing hands as to me this was primarily a learning experience. Taking the concept of money out of the equation also enabled me to dive into domains and development outside of my experience. Essentially, the pressure to perform came down, allowing me to allow myself to venture into the unknown more easily.

In that regard, the journeymanship differed starkly from being a typical consultant. However, the impact of having someone from the outside join the team for a limited time still turned my tour stops into noteworthy events for the teams I joined. And it became even more so when I was increasingly being asked to facilitate mob programming sessions. So naturally, I did.

With very few exceptions, every team I worked with was completely new to mob programming. What they lacked in experience, they all made up with enthusiasm and eagerness to explore and experiment.

My personal mob programming journey started back in 2013 when I was introduced to the concept by Ville Svärd and Tobias Anderberg. The introduction came in the form of a ten-minute lightning talk, but it was all that was required to pique my interest. A few months later, Woody Zuill visited Stockholm for the very first time and the rest, as they say, is history.

Where I worked at the time, my team started experimenting with mob programming. Though we initially didn't end up mob programming continuously, over time, as new hires joined the team, we started getting into the habit of almost always having a mob running. Most of the time we simply occupied the conference room, breaking up the mob when others needed it.

When visiting and facilitating other teams during my journeyman tour, I noticed the same pattern. Mob programming, when seen as an experimental and time-limited activity, warranted the use of a conference room. Rare was the office that had the amenities for an ongoing mob.

And this brings us finally to the topic of this text; what makes mob programming stick? Assuming equally good experiences when introduced to the concept of mob programming, what makes one team continue as a mob and what makes another team revert?

The possible reasons are of course legion. Yet, for a team that has come to the point that they actually have mob programmed for a few days, I will contend that chief among them is the lack of influence on the physical working environment. Many teams have long-reaching authority to pick and chose the tools they want when it comes to their digital working environment, but few seem empowered to throw out a few tables, rearrange the remaining ones and wall mount a suitably large display.

Notice the use of the word empowered. I'm confident that a lot more teams very well could get away with rearranging their work environment, if they only dared trying.

Isn't it odd how we developers can vehemently oppose being forced to use Emacs when after years of tinkering we have our own perfect Vim setup? Eclipse when we are IntelliJ die-hards? Atom when we'd rather stick to Sublime Text? And still, we consider the placement of a few tables and the assignment of seats to be next to set in stone. The sanctity of an office layout that must not be disturbed by the ever-changing needs of a team.

As a consultant, facilitator, or journeyman just passing by, it can be hard to empower a team to getting the working environment they need. Often there can be red tape that needs to be cut, expenses that needs to be approved, or management that needs to be convinced of the permanent requisition of one of the conference rooms. Activities to overcome any obstacles in the way of keeping the mob up and running. Activities handled by our unsung hero: the mob enabler.

Just like any other role, the mob enabler needn't be always played by the same person, nor need it be played by a single person. However, if your team is blessed with a manager that appreciates mob programming, mountains can be moved.

Finishing my journeyman tour, I came to work for Agical and through them TV4, a Swedish national broadcasting company. As luck would have it, Woody was in town when I was about to introduce my team to mob programming so we managed to spirit the team away for a full-day workshop on the subject. The next day a dedicated mob space was put in order. The week after better displays had been wall-mounted, various service accounts created, and a dedicated mob computer was in place. Three months later, the lone mob setup had been replaced with two, enabling two mobs to work. And I don't believe it will end there. Several other teams have been trying mob programming so the utility of having even more mob setups is evident.

Indeed, the team taking mob programming to heart and embracing it was a prerequisite for having an ongoing mob at TV4. But throughout this time, our team lead and manager has been cutting red tape, looting hardware, and pushing tables around.

Thank you Kristian Saebdal, enabler of mobs and mover of mountains extraordinaire!