NLJUG – Nederlandse Java User Group NLJUG – de Nederlandse Java User Group – is opgericht in 2003. De NLJUG verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Java Technology.
I remember a time, when at every code review, I was screaming inside and dying bit by bit at every line of code. Another piece of code that has no structure and no consistency; another layer is leaking into another one—the nth solution for the same problem inside one application. Put in the mix the long development time and switching team members, and we have the perfect formula to build monsters.
Door: Magdolna Szilágyi
This is what many software developers and I have experienced during the years. How could we eliminate at least one element from this equation?
Can we make the current team to work as a team, instead of a group of individuals that work on the same thing in parallel? Because, more often than not, team members express their different views through code, which leads to an inconsistent, unstructured, and unmaintainable project.
Then I read for the first time about mob programming: a software development approach, where the whole team works together on the same task, behind the same computer at the same time. Could this be the way to enable the team to collaborate as one mind and one soul? Is mob programming here to the rescue? Can we build a better team and make the codebase clean?
So I challenged the team to go mob!
The thought of putting 5 strongly opinionated developers working behind one laptop, at the same time, working on the same thing, made the team anxious. “That sounds ridiculous!” – they said. Well…we still did it!
Worst-case scenario, we will get an opportunity to know each other better and to shake things up from our comfortable chairs and daily routines.
The rules
We scheduled the first mob programming session, we booked a meeting room for a couple of hours, and we started as initially developed with a few easy rules.
- One computer – There is only one computer in use for programming.
- Being open and considerate toward new views and ideas and treating each other with kindness and respect.
- Driver/Navigator pattern: The Driver sits at the keyboard and writes the code. The Navigators discuss the idea being coded and guide the Driver in creating the code. The Driver is not involved in the discussion.
- Timed rotation: We rotate the Driver every 15 minutes, so no one is attached to the keyboard for very long.
We started our session by choosing a story to work on. Then the first Driver connected his laptop to a big screen for everybody to see it. The Navigators started the discussion on how to solve the story. There was only one problem. The Driver, who was not involved in the discussion, had the most knowledge about that specific topic. This was getting us nowhere, so early on, we decided to customize the rules to our needs. The first change was that the Driver could be involved in the discussion as well. However – essential – the Driver when typing must follow the Navigators. Otherwise, the Driver might “hijack” the keyboard and make changes without consulting with the rest of the team.
We navigated the Driver, and this was fine until another developer started typing. The typing went slow due to trying to figure out how to work with somebody else’s workstation and shortcuts. We had different operating systems, different development environments and configurations. So, everybody started bringing their own laptop and worked on that.
Every 15 minutes, we were changing drivers, and because everybody was using their laptop, we were pushing and pulling the work in progress code to the repository. We found the 15 minutes rotation quite disruptive and we were not comfortable with messing up the git history. So instead of timed rotation, we switched to tasked rotation. We split the story into mini-tasks, for example: writing a unit test, refactoring a method or a class. We found this more effective, also considering that code writing to discussion ratio at times was low and we produced no code every 15 minutes.
The first session left us with mixed feelings. We had our fair share of struggles, but we have also seen the potential to increase team collaboration. One session wasn’t enough to reach a conclusion. After all, we needed time and practice to learn how to do mob programming. We decided to make this a regular thing. Every 2 weeks a couple of hours or a full day, we were going mob!
The benefits
Some of the benefits were clear from the first session, and some we saw after a couple of sessions. For instance, it was evident from the first moment that this is an excellent knowledge sharing tool. We were exchanging handy tips and shortcuts to make us more productive with our IDEs. We were learning new things ranging from business rules to programming paradigms or cool new tech.
On top of that, it was a great team exercise! We had a chance to know and work better with each other. For a new team, it is especially beneficial because it will speed up the bonding process. It gives you a feeling of belonging and an assurance that you are not alone. It will help to work more like a team instead of together in parallel. Spending time together, sharing knowledge and frustrations builds stronger connections and makes members more committed to each other and to the common goal.
During the sessions, we had moments when we realized that we had different ideas about the scope of the project, and everybody was trying to push their own “agenda” on how to build it. It was the right moment of collective reflection, especially if we were under high pressure being focused on getting things done. It is a good time to slow down and see if the team is still on the same page and is going in the right direction. It helped us to bring the team on the same page regarding the vision and plans of the project.
Our biggest struggles were communication and listening. The most challenging part was to listen and to hear others’ opinion, rather than just running over our response in our head. But when we were put on the spot, we had to make our communication more efficient. We had to listen and think twice about how to express our ideas to be heard and understood. We needed to think twice and experiment on how to formulate your instructions for a junior, a senior developer, and non-techies as well.
And to my happiness, we were improving and cleaning our codebase! How? Because, as a team, we started finally picking up those low hanging fruits that we always postponed. We were discussing points and issues which otherwise were neglected during our day to day work. For example, code styles, best practices, possible improvements, and technologies. When discussing and making some agreements, we ended up expressing a unified opinion and decisions in code. The project started to look more like one great developer wrote it.
The learnings
It was not all sunshine and rainbows. Some sessions were better than the others, however, we have learned something new each time. As we progressed, we got a lot of insights on what can go wrong, how we can spend our time to get the most value out of it, and how we can improve.
For example, it was no fun to debug together. It was frustrating, difficult to follow, and disengaging. So we have learned to choose issues to solve where there is space for creativity, for instance, issues where we needed to build a new feature. It was more fun, we learned a lot and enabled us to collaborate more and better.
However, more space for creativity and freedom brings in more discussions and disagreements, which is not bad because this makes people think. But, sometimes, the conversation can get heated and frustrating. Try to moderate the discussion, and keep it civil, organized, and focused. Pay attention to interpersonal dynamics and people’s reactions. If somebody is hurt, you can point it out and discuss how to make arguments without getting personal. If somebody is confused, revise the previously discussed points and comments. Being aware of these dynamics and reactions can avoid unnecessary misunderstandings and, instead, the energy can be used to find the right solution.
Try to involve everybody in the discussion. To include those who are naturally more quiet or shy, you might ask directly for their opinion and encourage them with body language. For instance, smile when they say something, look toward them often, and show that you value their participation.
Some of the discussions can be tiring; that is why it is essential to have regular breaks. If, as a developer, you are also the facilitator and you are involved in the discussions, you might forget about the breaks. No breaks made us tired at the end of the session and less tolerant of each other. What worked for us is to set a timer for 50 minutes, and after the timer went off, we took a 10 minutes break. An excellent way to start up after the break is with some fun games! To keep the energy levels high, have some icebreakers and energizers prepared. This can light up the mood, boost team morale, and make people open to discussion. Games, as such, can be guessing each other’s favorite music, untangling yourselves or any other you find suitable and fun. If nothing else works, then bring some cookies! Everyone is happy when cookies are involved, and they are there as ultimate comfort.
After you have had all the discussions and you start typing, I recommend keeping your code changes scoped. If you intend to do a refactoring, think twice about what value brings to the session. For example, making the code compile is maybe not the best time spent for the whole team. In our case, we spent a considerable amount of time making the code compile due to a change to a variable type of a heavily used domain class. What worked for us was test-driven development (TDD). Since we are doing it for a short amount of time and we have a lot of discussions, most of the time, we do not manage to finish a full story. However, by doing TDD and seeing the test going green, it gives us a feeling of accomplishment
If your first mob session wasn’t as expected, don’t give up. If it is uncomfortable, that’s great! It means you are out of your comfort zone and starting to learn something new. Keep doing them regularly. The flow of the session and team collaboration will improve from session to session. Repeat, customize, and enforce the rules. They really do work. And always ask for feedback at the end of the session. This will help you to identify the problems, and for the next time, you can find a solution.
Conclusion
Programming is more about thinking than actually writing code. The mob sessions allow a variety of ideas to be expressed and discussed. All members have the opportunity to think about and respond to them. When there is a mix of ideas on the table it is more likely to come up with a great solution. This leads to group ownership and commitment because everyone has a chance to contribute to the discussion and to be heard. The final result feels like it belongs to everyone.
When all team members bring their strengths and skills to the table, it will lead to a more effective result than any of the parts alone. Power to the Mob!
Magdolna Szilágyi is a Software Engineer at Code Nomads with a passion for software architecture, clean code and effective teams.