I’m currently interning at a consulting firm “specialized in software architecture and Agile methods with a threefold-expertise in consulting, realization and training” called Zenika.
It’s a very fulfilling experience both on the human and technical side and the subject of this post incorporates these two aspects rather well.
We will be covering the following points:
Mob Programming is an approach in Software development that involves a team of developers in front of a computer, thinking, debating and finding solutions together while one of them takes care of driving the conversation and coding. The whole point of this practice is to find a consensus on problems and to produce something of greater quality as everyone can partake in the conversation. If you already know of pair programming (which involves two developers) then you probably already noted that it’s a similar concept but extended to a whole team.
I briefly mentioned why this practice can be useful, but I think it’s worth going into details with some examples.
Mob Programming involves the team in every aspect that goes into software development, from defining stories, to designing, testing and deploying. By thinking as a group, developers tend to bounce ideas off each other and find better solutions.
It also allows the team to go over their knowledge on the subject and perhaps explain it to people who may not have delved into a certain framework or design pattern, allowing them to have a concrete introduction to it.
Disparity of level may be the most complicated aspect to manage in Mob Programming in my opinion, as some individuals may feel left out or out of sync with the rest of the group, to avoid getting to that point, make sure to ask if everyone is following rather often and if someone seems to participate much less than others, try to include them through broader implementation questions.
Finally, it can help a team get closer overall, as it will create a deeper professional bond built over problem-solving and discussion.
On an individual level, Mob Programming has obvious advantages.
For example, my last session had us take someone’s project and tackle some of their bugs and issues. By taking a feature and applying good TDD practices to it all together I managed to understand some concepts on a deeper and more concrete level. Additionally, I did not hesitate to ask for precisions when something was being typed and was not clear to me, without disrupting the flow of the work.
I’m sure most of you already heard or used this concept in your current jobs, but hopefully some of you may be inspired to give it a try and understand the benefit of working alongside individuals who may think differently.
Thanks for reading,
Have a good one :-)