How did we finally get there? The first step was a one-hour presentation of the concept of Mob Programming by Woody Zuill in the Boston office of Amadeus IT Group. He graciously accepted to give this talk to us, and we thank him again for that. We are based in Nice, in the south of France, and attended the meeting via webex. One Scrum Master was very impressed by the presentation and talked about it to his team. So they asked me to give them more details about this “technique”, which I did, and at the end we decided to give it a try. The main reasons were:
- When working individually we accumulate some specialized knowledge, that we don’t share with the others
- When working alone, we usually give up the practices like TDD (and in fact the team had even never started to do TDD). Perhaps when working together, there will be a sort of emulation to use more good coding practices.
We decided to schedule five initial half-day mob programming sessions, as an experiment. Because that’s what agile is: trying things and see if it works for us. As I was a little anxious, I had a quick skype session with Woody Zuill the day before and he told me that the best way to start with mob programming is to try to find something to do out of the “business as usual” stuff. You can for instance start with some sort of coding dojo with the whole team, with a coding exercise like Fizz Buzz. There is no pressure when you do this exercise, and the team will be more able to focus on trying to develop good interactions.
Another tip that Woody gave me was to start with frequent rotations, something like every 4 minutes, so that the team members get used to those rotations (it can be counter-intuitive for a developer that is used to work alone).
Last but not least, Woody insisted that mob programming works well if you use TDD. If not, how can you be sure not to accumulate technical debt and defects when you mob?
So there we were, 4 people in the same room (unfortunately one of developer was in training this day). We decided to work on one of the bugs that the team had to solve. We started with one that was less complicated that the others (even if on this project, all bugs are complicated).
We used the Attila Buturla’s mob timer and there we went, 5mns rotations. It was interesting to see that from the very beginning, the team members noticed some simple things about how each of them configures its coding environment, and rapidly began to exchange tips and tricks. When you mob, you really share the details, not just the big picture.
The teams members quickly got used to rotating on the keyboard. Even if Woody Zuill recommends using the strong-style pairing style, we did not get to it, because sometimes the person at the keyboard was the only one knowing what to do.
As I said before, the bug we had to solve was quite complex, but we rapidly noticed that everyone could bring its own expertise to try to find a solution. At the end of the 3 hours sessions, the team did not solve the problem, but knew what documentation they had to look at to find the solution. As we had to leave the meeting room at the end of the 3-hours sessions, we decided that one of the team members would look at the documentation, and we would work again on the problem as a mob during the next session, which was scheduled two days later.
We made a short retro at the end of this first session, and one of the things that came up was that “it was fun”. The team had some doubts about whether it made them more productive than working alone, because they told me they already have great interactions throughout the day. We also decided that it is better to plan two half-day sessions in the same day so we really have time to solve a problem, and not stop in the middle. Or we can have two half-day sessions on two consecutive days.
Anyway, what stands out is that the team found that it was fun, and I think it’s really a good reason to continue the experiment. If we can make work fun, it will certainly increase our motivation, and hence make us work better. It’s as simple as that. I am pretty sure that we cannot scientifically measure if we are more productive with mob programming, at least not after the first sessions, but if we can notice that we work better as a team, it is a very good reason to keep on doing it. Next mob programming sessions are coming next week, I will continue to share our experiences in the next blog posts.