In my passage about the myth of lengthy Scrum meetings two weeks ago, I mentioned that people often misinterpret the Scrum events and leave all the pre-Scrum meetings to exist.
Code review is a common practice in many software development teams nowadays. There are various styles of code review, each serving different purposes. In traditional development teams, the developer submits their code to the source control, and a more experienced developer checks the code quality and logic before approving it for deployment. However, this process has been largely replaced by continuous integration tools like SonarQube.
Modern code review has evolved to focus more on sharing and collaboration rather than seeking mere approval. Developers come together and share the code they have developed over a period of time, leading to discussions and alignment. Afterwards, they update the code and adapt the coding standards.
This sharing-style code review enhances communication within the team, enabling everyone to be aware of the code written by others. However, as the team grows and more developers work on the same codebase, the volume of changes and code review content increases. What used to be a 30-minute code review session can now stretch to an hour, causing people to lose focus.
Since our team’s establishment, we have been conducting sharing-style code reviews after the Daily Scrum from Monday to Thursday. Over the years, we have fine-tuned our coding standards, ensuring that everyone writes code in a similar style. We then focus on the business flow and architectural design of the business process.
However, we sometimes unintentionally overlook minor issues in the codebase. These seemingly insignificant problems accumulate over time and eventually become significant issues. We end up spending several days adding missing automated tests and weeks refactoring the code to meet new business needs.
“Why did the big problem happen even if we have code review daily?” I asked. This made us rethink our code review process and consider alternative solutions.
We acknowledged that we occasionally ignored minor problems, and even when we did discover them, it was often too late to address them effectively. The feedback loop was too long.
Around the same time, new developers joined our team, and a new business initiative required skills that only they possessed. That was when I introduced mob programming.
Pair programming, or pairing, involves two developers working together towards a common goal, sharing a monitor. Mob programming, or mobbing, on the other hand, scales this approach by involving three or more developers, or even the entire team, working together with a shared monitor.
Mobbing encourages the entire team to focus on one task at a time. When everyone is watching the same monitor, minor problems are less likely to be missed. This approach enhances communication as it involves continuous discussion and significantly shortens the feedback loop. Consequently, code reviews can be eliminated.
After our first two-hour mob programming session, we watched a YouTube video recorded in 2012 that showcased a day of mob programming. The team was amazed by how well the people in the video worked as a mob for an entire day. It also made us realise how slow we were in adopting this working process, which has been promoted for the past 12 years. I recall a time in a previous team when I attempted to promote mob programming, but no one paid much attention. Sometimes, it takes a triggering event to bring about a solution.
Since then, we have been experimenting with mobbing. I am closely observing how the team works and grows during this period.
We have been experimenting with mob programming since I introduced it a week and a half ago. I am closely observing how the team works and grows during this period. It takes time to accustomed to the new practice, but I hope to work smoothly soon by continuously improving the working process of mobbing.