Blog

1. Introduction

In this article, I'll share my personal experience with remote mob programming, as a senior software developer. There are pros and cons, like with any other software development approach. First, let's see what mob programming is and how did we end up implementing it.

2. What is mob programming?

It's a development approach similar to pair programming where instead of two people you get the whole team to work on one ticket at a time. Sessions last the whole day, and you take breaks when needed. In a remote environment, one person shares a screen and others are watching and contributing then the other person takes over and continues where a previous person stopped. Idea is that every member of the team does some coding. In the normal-life environment, the whole team would gather around one screen and do the same thing.

3. How did we get there?

The company I worked for was going through an agile transition from Scrum to SaFe. Someone sold our management a story that SaFe will solve the company's long-lasting issues. 

We were on some agile meeting when our scrum master just announced that from that moment on we'll be doing mob programming since there is a sentence or maybe a paragraph in their agile handbook that says how mob programming is actually raising a team's efficiency. The whole team was shocked but we're all like, let's try this thing out and then drop it if we don't find it useful. I made few (more or less inappropriate) comments but wanted to see how this will go just out of morbid curiosity.

4. So, how did it look like?

We are all working remote because of the Covid19 situation. Imagine a team consisting of 6 senior and almost senior developers sitting in front of the screen and camera with headphones on for a whole day, while one person is typing at a time. Since that person knows how to work, it's like, binging the job for the others who watch. Others comment here and there or help when a coder gets stuck which does not happen often since we're not kiddies in kindergarten.

From a tooling perspective, we used Google Hangouts for screen sharing.

5. Observations

Efficiency and productivity

So, here we have a situation where one person works and others are watching or helping out. Instead of one ticket that is the result of mob programming, for the same amount of time, in normal circumstances, we would have at least 4 tickets closed (assuming they are of the same weight). In my opinion, this was a waste of time. My productivity was never lower, while my mind was overwhelmed with constant communication.

Also, I had a feeling that, since I'm not the one who's the coding of some functionality from the beginning to the end, I'm getting only some shallow meta-knowledge. Something about me not doing it completely made me feel distant and not completely familiar with the work that is done.

Focus on communication instead of work

When working like this, you're talking most of the time. But, we, old developers, are usually solitary beings. We do our work in our dark cave and we like to get into the flow since this is the rare good feeling this occupation offers. With mob programming, we're even deprived of that. Also, that person which actually does coding needs to verbalize what he/she's doing that is something we developers don't usually do.

Bonding with people

I must admit that mob programming helped my team to bond. We were all employed during the pandemic and started remotely. Some of us never met some other team members. We actually spent a lot of time together online, had some funny conversations, worked, had lunch together. It would be great if we would actually be able to have a similar relationship in real life when the pandemic is over and we start going to the office. Also, I never thought that people's character can leak so much through the way they work. You can see who is detailed, who is picky, etc.

Learning and evaluating the way we work

We had one great guy who was a lot longer in company than the rest of the team. He had more experience with the product we were working on and these sessions were very useful when dealing with parts of the system that only he knew about.

Also, when we watch other people code in real-time, we can actually learn a lot about ourselves, position ourselves in the developer hierarchy and try to improve when we see some practice that is a lot better than ours.

Distractions in a remote environment

When working this way in the normal real-life environment you are actually not on your computer, but doing sessions with others. In a remote environment, you're on your computer where someone is knocking on the door, a neighbor's kid is crying, emails arrive, people are pinging on Slack and you can't ignore it because you have to be sure that nothing is burning where you're the one responsible for it.

So, if you don't turn everything off in these sessions (that last whole day), you would have distractions and it would be not so easy to follow what some other person is doing. Also, if distraction happens just before your coding turn, it would bring you a nice burst of adrenaline. 

6. Conclusion - we decided to drop it

We were doing this for one sprint. On sprint retrospective, we decided not to proceed, except for situations where this is necessary - sometimes there's a need for a whole team to understand or help with some piece.