What do you do when two developers in your team mention that they have been stuck on a task for three days? At an insurance startup, the whole team decided to try-out mob programming. From the first day they started to mob, their knowledge of the codebase increased. Working together also helped them to get to know each other better and to be more efficient as a team.
Johan Rouve and Alexandre Victoor shared their experience in doing mob programming at FlowCon France 2019.
The team was already used to pair programming and was having lunch together, which made it easier to start with mob programming, as Victoor explained:
As you know, in France, lunch time is something sacred. It is quite common to take one or two hours to go to lunch. Quite often we used this time to practice TDD and refactoring doing code katas. Hence, when we started mobbing, we were not a group of strangers to each other.
Rouve mentioned that mob debugging was their most difficult challenge:
The first time we had to investigate an unexpected behavior, it was a real mess. Each time we rotated the navigator, the method to track the bug changed because everybody tried to do it the way he was comfortable with. Sometimes, in order to help the team move forward, you need to put your ego aside and follow an idea from someone else, an idea you are not comfortable with.
Mob programming brings the team lots of feedback. Victoor said that being together the whole time helps a lot when making technical decisions. It also gives them a lot of courage to tackle complex issues and tough refactorings.
Rouve mentioned that the main benefit of mob programming is continuous sharing and learning; plus, mob programming forces the team to be aligned on best practices and coding standards. "It daily improves our work by communicating more efficiently," he said.
InfoQ interviewed Johan Rouve, full stack developer at happn, and Alexandre Victoor, CTO at Comet Meetings, about their experience with Mob programming at Fluo, an insurance startup.
InfoQ: Why did you decide to try out mob programming at Fluo?
Alexandre Victoor: Well, long story short, we were working at a small startup and the code base was crippled by technical debt. It was quite difficult to meet business deadlines. We tried pair programming to improve the situation. That was great, but not enough.
One morning at the daily standup, two developers from our team were quite upset. After three days of hard work, they had to admit they were stuck on their task. This was supposed to be a simple task, but after three days of hard work they were not even sure they would finish it by the end of the day. Switching pairs was not an option for our colleagues, and there was no way that they would give up after so much time and energy was spent on this task. A business partner was waiting for us, we had to find a way to help them and deliver ASAP.
That morning after the standup we all sat together, the whole team, and started to look at the code. Before lunch we had a pretty clear idea of a solution and the task was done.
Then we start mobbing on the next task. Indeed, since that day, we have never really stopped mobbing.
InfoQ: What were the challenges that you faced, and how did you deal with them?
Victoor: When there is not enough knowledge around the table to answer all questions, mob sessions are more difficult.
When a group has to deal with a legacy codebase, when nobody has any clue about how the system works, mob programming is still great, but not magic. Also, it becomes almost mandatory to have a facilitator in the room to make sure that every voice is heard and nobody gets frustrated.
InfoQ: What has been the impact of mob programming on your productivity? And on the quality of the code?
Johan Rouve: We never really measured our productivity, as we switched to full-time mob programming so suddenly, so we don’t have concrete statistics. The only interesting fact that we can share is that we never missed a business due date.
The quality of our code has increased, and the risk of introducing bad code or even a bug is very low, because mob programming allows us to keep only the best of what each member can produce.
Victoor: I guess mob programming has led us to simpler code and a feeling of collective code ownership.
During a mob session, all ideas are discussed. This is really great for problem-solving. When you are alone and you need to solve a problem, you are biased. If you are a senior developer, you may think of a solution that you have applied in the past to a similar problem. This solution may not be the simplest, or the most efficient to the current problem.
When mobbing, everyone can speak up, share ideas and concerns. This is really a great way to build simpIe designs, shared by every single member of the team.
InfoQ: What have you learned?
Victoor: Lots of keyboard shortcuts and a bit of css ;)
I guess I have learned to listen more to my teammates. I am still often surprised by how different others can think, often surprised by how many different solutions can be applied to solve the same given problem.
Rouve: A lot of shortcuts. I really love these magical moments when you hear, "Wow! How did you do that?"
Mob programming teaches me to better collaborate with my colleagues and try to find a solution from multiple perspectives.
InfoQ: What’s your suggestion for when a team is considering mob programming?
Rouve: Select a task where your mob will be useful in creating an engagement and getting a positive impression.
You don’t need to do it full-time, but at least try it once. It’s an amazing experience.
Victoor: My first advice would be, "Do not rush". If your team is not ready, if your teammates are not willing to work this way, it is unlikely that the first mob session will go smoothly.
I would start with randori katas. A randori kata is a code exercise where everyone in the room works on the same computer. These katas might give you a glimpse of what an actual mob session could look like.
Then, when everyone is eager and feels ready for it, you might try to mob on a topic where there is a real "pain point" for the team, where a shared understanding is missing.
No matter what, do not force anyone to mob.
