Some of our colleagues have been practicing remote mob programming for a while and never want to work otherwise. We wanted to see what all the fuss is about and decided to learn from them first-hand.
We recently participated in the “Remote Mob Programming Experience” and thought we’d share our expectations, experiences, and general thoughts about the workshop. If you want more info, make sure to check out the official intro, too!
A few days before the workshop, we were granted access to a private GitHub repository which contained an empty project and a README with all the basic instructions for the setup. “But not all team members can write XYZ”—not to worry! A great thing about mob programming is that you’ll have a high amount of knowledge transfer. Not all of us knew Java (the language we used as an example) to the amount we needed for our project or the framework we’ve used.
At the core you will only need a few things:
- mob: a shell tool written in Go for smooth git handovers,
- a conferencing tool like Zoom or Microsoft Teams,
- the code editor of your choice and
- a collaborative whiteboard like Miro
Clone the provided repository, setup the tools mentioned above and you’re ready to mob.
At the start of the day, we had a quick intro about what lay ahead of us, talked about our expectations, backgrounds and had a brief getting to know each other. We were five participants plus two instructors: Dr. Simon Harrer (@simonharrer) and Jochen Christ (@jochen_christ). After a very brief reminder of the rules, we started our journey. Here is what you need to know:
- The camera must always be turned on, even when you leave the room—so that people can actively see that you are not in your seat (as they would in a physical working space)
- There is a typist, who shares their screen while the rest of the mob tells the typist precisely what to write,
- The typist changes regularly (depending on the size of the group). The order of typists is predetermined and recurrent.
With the basic ruleset out of the way, the product owner (played by one of the coaches) gave us the project objectives with quite a few requirements and some extra data. We started the planning phase right away, read through all the material and asked some questions back to the product owner. We concluded that we wanted to implement a small web app and started discussing about what to do first, which tech stack to use and the general architecture. When we realized that we were stuck in discussing minor details already, we decided to get our hands dirty by setting up the stack first and implement a small but notorious “Hello World” program.
And with that we started the first round of coding. In the beginning, the whole process was not smooth at all. As we mostly did not know each other, we had to get the hang of telling the typist what to write without interrupting each other and simultaneously preventing that only one person is doing all the talking. Changing the typist was not exactly smooth either, as git handovers and changes in screen sharing were a bit wonky.
After each round—a round is complete when each member has been the typist once—we had a short retrospective with tips and tricks, feedback from the coaches about what went well and what didn’t, followed by the next round of planning.
So we went back to the drawing board, assessed which features could realistically be done in one day and picked one. We drew a mockup for the frontend, which resulted in more questions to the product owner, thought about a model and went straight back to coding. The second round was already a lot smoother as everybody now had the same objective in mind, and we started to produce testable code. Skip some time and with a few rounds gone by, we really started picking up some pace.
After lunch, an unexpected visit from the product owner, more rounds and retros, we went from not knowing each other or mob programming and different skill levels to implementing our first feature. The handovers had gotten much smoother, we stopped wasting time discussing irrelevant things and overall, the level of concentration was remarkably high through all the six hours of working as a mob.
We even managed to implement a feature from frontend to backend: A website where the product owner could select any of the streets that were parsed from one of the raw data files that we had received at the start of the day. An incredible feat, if you ask us. At the end of the day, we concluded the workshop with a final retro. We also talked about how different mobs would produce a variety of results and approaches to the same project and shared our feedback about the day.
Our main takeaways
- We had a working project setup on all machines in less than two hours.
- We were exhausted after six intense hours.
- We were a team at the end of the day, even though we hadn’t even known each other only hours before.
- Mob programming requires stamina, concentration and discipline: It is so hard to hold yourself back if you know the answer but have to ease up so that you do not outpace the others.
- Knowledge transfer is immense: Everyone knows every part of the code, every architecture decision and every requirement.
In the end, we all had a blast, learned a lot about mob programming, got to know each other reasonably well for that short time we were together, and even whished for a second day of training to finish the project. Speaking for the two of us, we would love to try it out in the wild.