About a year ago, after JFokus 2015. My team had a retro where we talked about our favorite sessions — what we could learn and if we could try to improve something in our daily work from each session. I remember we decided to try mutation testing, but we felt the investment wasn’t worth it. We did the same for a couple of other things but I honestly can’t remember what they were. The one thing that changed everything though was Woody Zuill’s talk on Mob programing. We had done one or two 1–2 hour session of mob programming before, where we had simply booked a room and solved a hard problem together. Since we had liked that we thought “why not?”

Example of a mob setup. Blue shirt not mandatory.

The next day we took a computer, connected it to a TV and started coding on a sofa. We didn’t do any preparations so we took what we had. We used a phone as a timer, decided on a rotation time and just went with it. Our communication was horrible, we discussed small things for way too long and didn’t produce at a very good pace. We all had a lot of fun that day though, and we felt we learned a lot. When I left the office that day I was totally exhausted.

The next day we decided to try it for at least a week before we drew any conclusions.

After the first week we had not improved our mob programing skills much, but we had aligned on the small things, didn’t need as much discussion, and started producing at a good pace again.

Fast-forward a year and our workdays now center around mob programming. The kanban board mostly has one or two stories in progress. We do have a stand up but it is less about sharing what we did and more about if our current story is going well, if we should slice it, etc. After the standup we decide if we should have something in addition to the mob and highlight if we have any meetings. Most days though, the mob goes on the entire day. It could be that everyone has meetings to attend, interviews to hold or personal errands to do. But the mob always goes on. So no stories are halted for long, and we produce at a constant pace.

We often get the question if we think it’s better to use mob programming than pairing or working alone. I must agree with what Woody says — for us it is way better, but i’m not claiming it’s better for everyone. We’ve found that we are much less likely to deviate from our agreed upon processes when there are more of us in the mob to point out that we’re straying from our working-agreement. Four people are more likely to remember and point out that we should verify the acceptance criteria before claiming something is done, e.g that we should have a test before writing production code. It is very unlikely the mob will take shortcuts and ignore the Sonar warnings.

Another question we often get is if we mob on small simple things. That I would say varies. But what we have noted is that we are more eager to automate things when we sit in the mob. That has led to not having as much small simple things.

Overall, doing mob programming for a year has been exciting. There has been times when it felt like a waste of time, there have been times when you learned more than ever. New members in the team this year has gone from scared and skeptical to true believers. But one things is for sure, for us mob programming was great. If it will be for you I have no idea, but why not try a week or two? What do you have to lose?