The last few years have been times of dramatic change in our lives. We have all been shaken by a worldwide pandemic and an ever more digitalized and globalized workplace.
Amid these life-reshaping events, we have been trying new methods and tools to adapt to our changing realities. As part of this effort, PayFit as a whole has successfully pioneered a Work From Anywhere (WFA) policy, in which employees can work all over the globe, taking advantage of the digital nature of our work and the maturity of remote work tools.
In the midst of all of this, our software development squad has started experimenting with Remote Mob Programming approaches, both to take advantage of the tools we have at our disposal for remote work, as well as to improve the quality of our product and our teamwork efforts.
Our context
We are an agile squad composed of 3 software developers, 1 product manager, 1 design manager, 1 engineering manager, and 1 part-time SRE engineer.
There are several squads just like ours at PayFit, so this article is about our own experiment, not a company-wide process.
Our product vertical consists of what we call "Time-On" management: that is, the management of employees' time during their worked hours, with key features such as time-tracking, clock-in/clock-out, and compensation based on worked time, amongst others.
We could summarise the most salient features of our work environment as follows:
- We are a newly formed team (Time-Management team split into Time-On and Time-Off squads in September 2021) – so the squad is 3 months old at the time of writing.
- The oldest developer on our team has been just 9 months in the company.
- We are still creating a team culture and agreed best practices.
- We are a non-collocated development team.
- Because of Covid19 and the non-collocated nature of the team, our onboarding process has mostly been remote.
Given these special work circumstances, we have been trying different approaches to organize our team and try to create high productivity and high collaboration workflow, even without being all together in a traditional office space.
Our latest discovery, and one we are particularly excited about, is Remote Mob Programming.
What is Remote Mob Programming
Let's first start with collocated Mob Programming. Woody Zuill, a pioneer in this way of developing software, defines it the following way:
“All the brilliant minds working together on the same thing,
at the same time, in the same space, and at the same computer”
Even though it follows the tradition of pair programming, this definition can seem rather counterintuitive for someone not familiar with collaborative software development methods.
The Driver-Navigator model and its derivatives
The pair-programming way of developing software has long used a technique called the "Driver-Navigator" model —metaphor taken from rally races—, to coordinate the pair of programmers that jointly work on the same development task. It consists of assigning different roles and responsibilities to each one of the developers: one, the driver, is the one responsible for "holding the wheel" which in this case corresponds to doing the actual "typing"; the other one, the navigator, is responsible for "looking into the future" and planning what are the next steps needed to move forward into accomplishing the task at hand. After a fixed period, the roles switch.
Quoting Woody:
"...for an idea to go from someone’s head into the computer it must go through someone else’s hands. After some agreed-upon interval, the roles switch..."
We can think of the driver as a sort of smart I/O device, which receives high-level commands ("we should refactor this class into two classes and compose them") instead of textual input.
Mob programming extends the two-person Driver-Navigator model into a group Typist-Mob relationship: one person is typing at a given time, while the rest of the mob is discussing how to resolve the task ahead and assuming the role of a group "Navigator".
Adding "remoteness" to the mix
Of course, life today is very different from what it was just 2 years ago. Today we have a global pandemic that has fundamentally disrupted the way we used to work.
As can be seen from Woody's quote mentioned previously, Mob Programming is about “...all the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer”, there's a physical presupposition that the mob is collocated in the same space. Woody's book is very explicit about this point and has quite a bit of detail on how the actual physical workspace should be set up for a successful Mob Programming experience.
But, of course, in our current context, this is just not possible! First of all, during the Covid restrictions, remote work became a necessity. Along with that, PayFit took the opportunity of the advantage to offer one of our most interesting work benefits: the Work-From-Anywhere policy. Currently, our development team is a completely distributed team, without any members living in the same city.
Thankfully, digital technology has reached a point in which Mob Programming can be perfectly practiced remotely. Since the pandemic is something that has hit the whole world, there's a lot of great work being done by the community to support remote Mob Programming work. In particular, the website remotemobprogramming.org has been a great resource to start. Its authors have published a little booklet with 15 principles that can serve as a base from which to spawn a Remote Mob Programming workflow. The authors of this website and booklet have also put together a fantastic CLI tool to help with code handoffs between developers, which I will refer to in the following sections of this article.
Our findings thus far
It's been more than 3 months since we started experimenting with Remote Mob Programming, and we can say the experience has been extremely positive! In particular, we have noted the following properties to emerge from our dynamic teamwork.
Fast flow
One of the most interesting things we have observed while mobbing is the state of "being in the flow". Whoever has played in a music band, or played a team sport has had the experience of being in flow, when every movement seems coordinated between different team members and everyone's concentration is perfectly focused on the task at hand and nothing else.
Of course, solo programming also has moments of flow, but our experience has been that with mob programming, at its best moments, the state of flow can be enhanced, and more creative ideas can be created by having all the team working at the same time on the same problem. We can really feel how the work moves forward, from tests passing and problems appearing in front of everyone and solutions being created by everyone's input. Although the state of flow is not always reached and once achieved it can be lost, once the team has reached it, everyone is deeply attuned to what is being worked on, so work flows smoothly, all eyes are upon the code, errors are caught fast (I'd say immediately!) and team productivity is at its peak. Flow is the optimal state of work we strive for!
Knowledge sharing
When mobbing, the team is working together and different perspectives on how to get the job done are constantly being shared and confronted. Besides the discussion on how to approach a problem, in which more theoretical perspectives are shared, watching the typist go through the actual implementation and sharing tips on how to implement and use our tools can be a great way to learn and share tips and tricks of our trade. We have all been learning a great deal from each other these last couple of months.
Not only is knowledge shared in terms of sharing expertise and theoretical knowledge, but also on a more pragmatic and information sharing level: we all know the latest "news" on every front of work because we have all been talking all day! There's no need to keep updating people on the latest developments since everyone is always on the latest page! This is a great contributor to easily reaching flow and avoiding the need to constantly sync between team members.
Collective decision making
Since we are all working together, decisions are made together in a deliberative manner. Different points of view are constantly shared and agreements are made on decisions. This makes decisions feel legitimate between teammates and no one feels that decisions are being forced by mere authority.
We have found that in software, coming to an alien codebase is always a difficult process: things seem out of place, the "why" of decisions is lost and the urge to refactor, or at least criticize is almost impossible to resist. Of course, the codebase is generally perfectly fine, but the lack of understanding of how the particular design was reached makes the code seem inadequate and never fully legitimate.
On our mobbing sessions, we have found that the code written, even if having its flaws and imperfections, is well accepted by the team because everyone knows which parts will need improvement, which parts have been purposely implemented simply, and which parts have had a deeper effort to improve some aspect such as performance, flexibility, scalability, etc.
Collective code ownership
In the same vein as collective decision making, the result of this process of shared creation is a product —our codebase— that is the fruit of our shared effort. We all have shaped it, at least in part, as we think it's best and is proud of it. There's no part of the code that we have produced during mobbing that is alien, it's all ours and we have invested into making it look nice and pretty. We are proud of it!
This shared ownership of our codebase has 3 immediate advantages:
- No person in the team has secret knowledge that no one else has. If someone is on vacation, there's no secret knowledge that only that person has that could block the team on certain initiatives.
- Everyone cares about the state of our whole codebase. The code belongs to everyone, not in an abstract sense of collective ownership, but concretely and tangibly of everyone having sweat over it.
- Technical discussions tend to be rich since everyone can refer to different parts of the codebase and in general all of the members of the team have a rich understanding of how our full scope of code works and its different parts interact.
Creating a team identity and ethos
Since we are a newly formed team, we are still establishing team identity. We all come from slightly different backgrounds: some have more experience in frontend development, others have experience besides application development and more into infrastructure concerns, yet others have experience in management and teamwork. All these different backgrounds enrich the way our team looks into problems, but it can also lead to conflicting views on the same topic.
By mobbing together we have been able to talk and create our own shared narrative, in which our different perspectives have been amalgamated into shared values and metaphors into which a team identity and ethos has been formed. We have been creating shared notions of what good code looks like, how much effort we think we should devote to testing, what is an acceptable wait time for a CI pipeline, amongst many other topics. Most of this knowledge becomes something tacit that each of us carries within ourselves in the way we look at problems and makes working together much more enjoyable. Flow is much easier to be reached in these conditions sharing an outlook.
Avoid “death by meetings”
This last topic is a bit controversial since mobbing could be considered one long meeting. The fact is that when things are flowing, it does not feel like a meeting. The dread that can be associated with meetings comes from the fact that meetings, a lot of times, and for a lot of the participants in them, are the opposite of flow; they are flow stoppers! Meetings have a start and an end in which context has to be switched and flow stopped. Besides their time-boxed nature, meetings bring a lot of people to the table, but most of the time only some of the people involved are engaged, whilst the rest are on an idle await mode only to join for specific topics of discussion.
On the time we have been mobbing, we don't need sync meetings, since everyone is always in sync on the latest developments. Besides, since mobbing relies on rotating the roles between the typist and "thinker", no one can be completely disengaged from the mob, and people tend to be actively involved all the time.
Tools and gadgets
To get our Remote Mob Programming experiment working, we have relied on a small number of key tools without which we would not have been able to get off the ground.
Slack Huddles & Zoom
Just when we started our Mob Programming journey, Slack released the first version of their "huddles" feature. Huddles are a simple way for people to join a shared "live session" on Slack. It has a minimal feature set: basically screen sharing, voice call, and a screen drawing functionality, but in its simplicity lies its allure. The tool is so simple that without even trying it became our default tool for mobbing sessions.
Sadly, after a great initial start, huddles have been flaky for us during the last month, so we have moved to Zoom which, while a great tool, is not that transparent and we have to think more about it.
Mob CLI
The same people that put together the remotemobprogramming.org website have put together a wonderful little tool to help with the fast handover needed during remote mobbing sessions. On colocated mobbing, people share a physical computer. On remote mobbing, we must somehow be able to quickly and painlessly pass the control of the input from one typist to the next.
In the beginning, we tried to use the Visual Studio Code live-share feature, which works in a Google Docs sort of way: everyone is editing code live on the same files. The idea sounds great, but in reality, it had a couple of drawbacks: two developers would get carried away and start working in parallel at the same time, making the collective design and fast team-flow just not happen. We would find ourselves after some time just working in parallel without discussing what each one was doing, and the mob sessions just turned into regular solo programming but with an open Zoom meeting.
The Mob CLI tool (http://mob.sh) on the contrary, enables a simplified Git handover workflow. Using this tool, any user starts a mobbing session, which creates a new git branch on which the team will work.
The tool is so simple that it has only 3 basic commands to get started: "mob start", "mob next" and "mob done". Let's illustrate its use with a simple example.
Example: Let's say we have 3 imaginary developers, Alfonso, Alex, and Visoth.
Alfonso starts the mobbing session and sets the timer for 15 minutes with the following command:
alfonso$ mob start 15
This will create a new git branch, starting from the currently checked-out branch, and set a timer of 15 minutes. After the time is up, a voice will say "Mob Done" and a desktop notification will be displayed.
After this, Alfonso will handoff his changes to the next developer with the following command:
alfonso$ mob next
This will push any changes with a generic commit message into the mobbing branch and allow any other developer to take over the typist role.
Let's say Alex decides to take the typist role next. He will just issue the same commands:
alex$ mob start 15
alex$ mob next
Finally, it's Visoth's turn:
visoth$ mob start 15
If after Visoth's turn at the keyboard the feature is done, the team can decide to merge the changes back to the branch from which they started working. For this, Visoth issues the following command:
visoth$ mob done
This will ask for a commit message and merge everything back into the original branch.
For more information just visit the project's website which has excellent documentation.
Whimsical & Miro Boards
The final tool which we use all the time during our mob sessions is online whiteboard tools. As they say, sometimes an image is worth a thousand words. Especially during initial design discussions, we mob over diagrams that are later on used continually during the actual mobbing when certain design decisions need to be further explored and discussed.
We also use these tools to make notes, lists, annotate important decisions and share our developments with other teams, architects, and, in general, any stakeholder we need to communicate with outside the team.
We use both Whimiscal and Miro indistinctly.
Recommendations for first-timers
Things I would suggest for the first session based on our experience so far:
- Try to have a clear objective for the session (having 1 clear user story seems ideal).
- Make sure the tools you use are simple and are super reliable (everyone is well-heard over zoom, code editors are all properly set up, etc.). Tool malfunctioning has been one of the biggest sources of losing flow.
- Since this is the first session, everyone will be adapting and learning how to mob together, so it’s better to be relaxed and create an atmosphere of collaboration that tries to be too rigid on following “the rules”. More introverted people may feel a bit overwhelmed by the experience at the beginning, so creating a safe environment for everyone is critical.
- Try to end up with a short retrospective on what failed and what worked. Did you guys get into “flow”? What got you there? What took you out?
Conclusions, next steps (and other quasi-philosophical diatribes)
I may be biased because of our excitement with this new way of working, but I really think Remote Mob Programming has been a game-changer for our team! Given our context and the specific challenges we have, this way of working has made remote work extremely satisfying, not only on the quality of the software we are delivering but also on having a great team working environment. We get to "be together" all day and keep a close-knit team, even though we are not collocated.
Still, it's early on our Remote Mob Programming journey and we have a whole bunch of things to learn. In particular, we want to explore the following:
How can we maximize flow?
- Having 1 clear objective per session before starting.
- Further exploring the driver-navigator model.
How can we incorporate UX and Product into our mobbing sessions?
- Should UX people participate in backend and infrastructure-only tasks?
- Should we only involve them in user stories with direct user-interface impact?
Should we add some asynchronous workflows to the mix
- Full-day mobbing can be very exhausting!
- Should we mob half day and do async work the other half?
Software development, as in many cognitive-intensive occupations, is often seen as the work of some lone individual contributor: the product of his mind —or some other ethereal entity like that— and his computer. Even if we understand that the full software delivery process is a very collaborative activity, the act of programming is often thought of as a solitary activity that happens after all the coordination has been somehow done.
It's not necessary to dig into the history of how did we come to think of "knowledge-work" as something to be done by lonely "minds" to see that this is not the case for many real-world occupations. In our world, a lot of "cognitive-intensive" tasks, which require deep expert work, are carried out in public amongst a team of experts, all working together at the same time and in the same place. Examples of this could be an operating room, where doctors of all specialties work together at the same time, in deep concentration, all perfectly coordinated to save someone's life; or the NASA mission control center, where for each mission, all the experts are together, looking at the same gigantic screens in front of them, each one collaborating on the same task at hand from their unique vantage point.
The fact that writing text has, for most of human history, been a solitary occupation, does not mean software programming cannot be a social endeavor. The conclusion that programming must be a solitary task rests on two unquestioned assumptions that can and are questioned by Mob Programming:
- Writing, by its very nature is something to be done by a single individual through their hands and some form of very closely attached "personal tools" (be them a pen and a sheet of paper, or a typewriter). But, digital technologies change the nature of the text writing activity, making writing text something that can be effectively done collaboratively.
- Writing is a solitary activity since it must be inspired by the intimate soul-seeking and mindful reflection of the writer. Software programming also involves "writing text", but it's a very different activity from other forms of writing, especially the writing of the narrative text. The fact that it looks similar in the way it is carried out (by typing words) must not lead us to believe that in its content it is the same activity. Not all typing is writing.
Now, that said, doing some cognitive-intensive tasks in a group does require a high level of coordination and discipline that is different from what we generally use when we are working alone. That's what Remote Mob Programming principles and practices are all about!
That's all, for now, folks, if anyone is interested and wants to follow up on the topic please reach me at alfonso.pola@payfit.com!
