At Netfonds we are working in 2-week-long sprints. Every fifth sprint is our I&P sprint – time for I(nnovation) & P(lanning)! During this period, we took one day to experiment with mob programming – a couple of developers and a freelancer, Thomas Hackbarth from codecentric, who had some experience with it and helped with his advice, as this was all new to us.
What is mob programming, and why should you try it?
If you now think about angry torch-wielding men or dancing flash mobs, you are far from the truth. But all mobs do have one thing in common – a crowd. So mob programming “just” means multiple people programming together. The evolution of pair programming (two people), so to say. But it is not as easy as “just” suggested because more people – more opinions, but more on that later.
What are the benefits exactly? A usual day as a developer: You start with your first ticket, but then you need to get some information from your product owner, who is busy and can’t answer straight away. So you grab your second ticket because why bother waiting? You finish this ticket at a blazing speed and open a new pull request, but now you need to wait for the code review. Well, now you have to wait again, and you cannot finish your first ticket either because you still have no answer for it. Then straight on to your third ticket! After another hour, you get your reply for your first ticket. And, oh, there are also some suggestions on your code for ticket two. But you are still working on your third ticket. Now, you have three open tickets 🤯.
Entering the stage to put you out of this misery: mob programming. You and your team start working on the first ticket. Ideally, your product owner is also on board and can answer questions immediately when they are needed. The rest of the time, they are more of a silent listener and can work on other stuff. The developers are working together respectively, alternating on the code. This way, you can skip the code review because everyone involves from the beginning, and knowledge gets distributed. The four(or more)-eyes principle also leads to fewer bugs and better code quality.
Ready, set, … go?
We tried three types of different mob programming styles on our workshop day. Before I tell you which ones, you first need to know which roles the participants could have in our session:
- The driver 🧑💻 – Your keyboard, does only what he’s told. Does not comment on the coding process and definitely does not code his own ideas 😱!
- The navigator 👩🦱🧭 – The captain, the boss, call him what you will. His word is the law. Tells the driver exactly what to code.
- The researcher 🕵️ – The handyman of the navigator. Can look up things for the navigator or can be asked for advice.
- The observers 🤐 – Everyone who does not have any of the three roles. Sits there and enjoys the view – silent, of course!
Because only the driver can write code, you don’t need any collaborative coding tool. We used Google Meets to speak to each other while the driver shared his screen. When it was time to change roles, the driver would commit their code to GitHub, and the next driver would check out the repository. We also used the handy website Mobti.me to time the coding sessions and pick the following individuals for the roles.
All rounds have one thing in common – 8 minutes of coding, then switch. So let the games begin!
Round 1 – Driver 🧑💻, Navigator 👩🦱🧭 & observers 🤐
In the first round, we had one driver, one navigator, and everyone else was observing and silent. We switched every 8 minutes, where the driver would become the navigator, and one new person would become the navigator. We did this until everyone in our group had all roles.
After this practical part, we would reflect on what went well and what went not so well. Here are a few key findings with some improvement ideas:
- Setting up the project right from the start next time
- The first few people had a lot of trouble even setting up a basic project because packages were missing and autocompletion did not work. This took a lot of time because the timer would run out, and the next person would start all over.
- Lots of different approaches
- After the navigator changed, we often experienced that the upcoming navigator would scrap the already written code and start with a new approach to solve the problem. That led to a lot of dead code or orphaned functions.
- No clear vision or goal
- Ties to the point above, but because nobody could talk with each other, everyone kinda made his own thing.
Round 2 – Driver 🧑💻, navigator 👩🦱🧭 & researchers 🕵️
In the second round, we tried with one driver, one navigator, and everyone else was a researcher. We also followed the same rules regarding switching and timeslots as in round one.
- Overall it was better
- Everyone was more involved and did help the navigator if needed. If we were stuck, multiple people could look for solutions if the navigator wanted it.
- But we still had no clear vision
- There were fewer do-overs, but the short timeslots often weren’t enough to complete the thought of someone, and the next person would not continue as imagined.
Round 3 – Driver 🧑💻 & navigators 👩🦱🧭
In the third round, we had one driver, and everyone else was a navigator. Still, the other rules kept the same.
- A lot of opinions
- Without the sole decider, everyone could try to force his opinion on the driver. Which resulted in some discussions, and the driver did not know who to listen to.
- We kinda moved to the rules of round 2
- ****After a few driver-switches, it became clear that the same few people were taking the lead and driving the code forward. Which also resulted in perhaps more introverted colleagues saying nothing at all.
Would we do that again?
First things first: All of these methods get used by some companies, and there are also some other roles and rules like the ones described here. We only tried these three, but we still found some lessons for us:
- It is substantial to have a common ground before you start implementing.
- Next time we would try to have ToDo-list or start with code comments, which would give a reference of what we are trying to do.
- Also, we would set up the code to work in our different IDEs before features get implemented.
- It helped us to feel more responsible for OUR code as a team.
- It also helped to see other developers‘ approaches to the problem.
So yes, we would give this another go for sure! But we also have not found the holy grail with these tried methods. We probably would also try to play with the length of the single rounds, as the 8 minutes felt very abrupt when you are still new to this type of programming. But overall it was a great experience and trying new things always brings you forward, anyway!
