I got a lot of positive feedback on my last post about mob programming (in Swedish). So, as my team has done more mob programming, I thought I should share some insights we’ve gained up until this point.

For those who like to read a lot

We learn a lot by working in a mob. Not only specific coding parts, but also about our individual thought patterns when it comes to solving problems. It is a challenge however when we all have different levels of knowledge, experience and ways to look at things. This has been a source of lengthy discussions where we try to explain to each other just how we would want to solve a problem, instead of actually solving it. Is that a problem on its own? Difficult to say. But one thing is for sure, and that is that these discussions are helping us getting an understanding of how our fellow team members think. Which in the long run is a step towards aligning the team’s way of solwing problems in the same direction.

When it comes to accomodation and tools we’ve discovered that it is a bit of a pain to always have to book a meeting room. Especially when the rooms available for booking tend to not be free for us to book during a whole day, resulting in us having to break up the session to move to another room. The TVs and chairs available aren’t of the highest standard either and definitely not adapted to lengthy programming sessions. A hurdle in the actual programming process is having to code in a text editor other than the one a person is used to. In our team we are as of to date using Sublime, Emacs and Vim. Add to that each and one’s own personalized shortcuts and hotkeys that are well programmed into our spines. I don’t know how many times I’ve tried to execute an Emacs command within Sublime, with horrible results …

The mob programming process as such is very strict and has many rules to follow. But as with everything, it is easy to start cutting corners and not comply by the rules. For example we’ve been quite bad at respecting the timer when to switch driver and navigator. Same with taking regular breaks. The latter being of great importance in order to keep focus and energy at a satisfactory level. I guess what we need to remember that the rules are there for a reason. There are people who has been working with the process and shaping it for many years, they know that this is how it has to be done in order for the participants to get as much out of it as possible.

A very specific issue that has surfaced during our mob programming sessions is the lack of a dedicated UX person in the room. Although we might not realize it, as programmers we are making UX desicions in every piece of code we write. May it be in regard to response times or how something is present on our sites. We have on so many occassions asked ourselves, how will this affect the end user? We have said “we should have had UX with us in this room” plenty of times. It is worth to point out that we do have UX people in our team, and it is a bit of a DMU thing to not have an optimal process when it comes to syncronizing development and UX. We’ve acknowledged the problem on both the development and the UX front and are trying within our team to become more aware of UX problems within the development process and vice versa by different methods. But I won’t go into any details here as it feels like a completely different blog post!

… and tl;dr

I’ve summarized the text above in the following lists:

The positive things

• Sharing knowledge
• Getting to know each other
• Solving problems by discussing them
• Eliminate single person dependencies and “deliveries”
• Real team building
• Bringing everyone to the same level of knowledge
• The focus that comes with working on one task/problem only
• It is great fun! Also, I partially get my social needs satisfied
• I learn a lot when we discuss and program together
• We align how we think and learn to see things from different perspectives
• The work will continue although a person leaves the room
• “Mob programming can seem time consuming at the beginning but in the long run we gain a higher velocity and increase focus while also avoiding single person dependencies. Thereby the work we do as a mob is more time efficient.” - Karro

The negative sides

• Difficult to keep focus when not being the driver or navigator
• It is more energy consuming in contrast to programming alone
• Programming in another text editor than the one I am used to
• Working within a code base that contains Javascript, CSS and Ruby
• The lack of rooms dedicated to, and accomodated for, mob programming
• Challenging with different levels of knowledge
• It is difficult to focus in regard to cellphones etc
• Easy to start cutting corners in the mob programming process
• It is difficult to leave the room when one has to do other things, FOMO
• Being dependent on one person’s computer to program on
• Programmers making UX decisions

A product owner’s perspective

I also asked our product owner how it feels having a whole team of developers working in a mob.

• It creates a unification when it comes to the chosen solution. No one can say during the morning meetings that it was someone else’s fault.
• A commit to being a team is required. A person can’t argue that they have something more important to take care of.
• It is a fast method to drill junior developers as well as making senior developers realize that they might be stuck in their ways.
• It takes a product owner who is comfortable with the time mob programming session takes. The session will eat a lot of time if it become ineffective.