Mob Programming? After all, I suppose it would be frightfully dull, and boring, and completely… completely wonderful.
During my years as a mob programmer, I have both loved it and hated it. And I have concluded, it is not the Mob Programming that is good or bad. It is all about the team. If the team is healthy they will love being mob programmers but a dysfunctional team will probably kill each other if they are forced to mob.
It’s been more than five years since Woody Zuill started to popularize Mob Programming, the development practice where the whole team works on the same thing, at the same time, in the same space, and at the same computer. Since then it has spread like an avalanche and nowadays there are hundreds and hundreds of teams using Mob Programming all over the world. There are also a lot of blog posts out there describing the practice so I promise this won’t be yet another “what is Mob Programming”-blog post. Instead, I bring you three real-life experiences from my life as a mob programmer.
During the years I have had the opportunity to use Mob Programming in quite a lot of different situations. I have worked with teams using it every day. I have used it as a coaching tool. I have been with teams using it on an “on-demand” basis. I have helped teams getting started and I have been a regular member in a mob team.
Sometimes it has been a fantastic experience, bringing up so much fun and increasing the learning and productivity a lot. It has made me go to bed with the same mood as a kid the night before Christmas. I just wanted to fall asleep as soon as possible so the night could turn into day and I could get back to work.
In other cases it was more like peeling onions for six months in a submarine, I had exactly no interest in going to work, the paycheck was my only motivation. I didn’t learn anything new, the delivery capacity of the team was extremely low and the team members seemed to hate each other more and more for every day.
The seventh heaven
What follows may sound like a sales pitch. You know, where small unicorns jump around in a pink wonderland, eating cookies and having an amazing time. Yet I promise this is real, it did happen.
We were a small team building an application in more or less a greenfield environment. I wouldn’t say that we were a dream team in the sense that we were top-notch developers that succeed with everything. We were more the average “developers from nine to five, parents in the evenings”-type of developers. Good programmers but not exceptional in any way.
We decided to build this new application together as a mob as much as possible despite our different working hours. Sometimes we were a mob, sometimes we were a pair, and sometimes we did solo work. If I take a wild guess I would say that 90% we were mobbing or pairing and the last 10% was solo work.
How did it go? Well, the application was a success, its users are really happy. I would say that the quality was good. We managed to deliver continuously to “test in production” but due to legal reasons, it ended up as a big bang release to the end customer. We were a few weeks late compared to the original plan but most of the delay was due to late changes to requirements. In summary, a well-executed but not perfect project.
Not perfect? So I guess you still wonder where all those pink unicorns are?
The answer is in the teamwork!
During those months it was a blessing to go to work. The learning curve accelerated. We were productive. We gave each other instant feedback. We were in total sync and everyone knew the whole solution like the palm of their hand. Therefore, reported bugs after release were fixed and released to production within the same working day regardless if someone on the team were on holiday or home with a cold. We had built a quality solution that we could be proud of while experimenting with new techniques and solutions. We made friends for life. I would absolutely call it one of my best working experiences during my 20 years as a professional developer and the foundation was us coming together, working as a team.
The horror experience
If the first example was like a sale pitch, this one will be more like an episode from the Twilight Zone. A painful tale of darkness and dystopia.
At the time I worked as a developer in a team where we decided to go for Mob Programming as our main way of working. Everything was looking extremely promising, we had the total backup from the company, they even hired Woody for a full-day workshop. We got our own dedicated mob area, a few developers in the team had worked with Mob Programming before and really loved it. It was probably the best prerequisites I had ever had for a successful mob team.
In the beginning, everything seemed to work well. According to Jira statistics we delivered more to production and the code quality increased. I thought that we were about to lift off, that we would accelerate from the good start. But gradually we fell into the total opposite. Productivity decreased, people started to nag each other, the mood in the team got lower every week. The focus in the mob was really bad, people kept on doing other things when not acting as driver and we found ourselves in endless discussions regarding every single solution we were trying to build.
Initially, I thought that this was the ordinary “storming phase” but it just kept on, becoming a worse experience with every week passing. The retros were the only time when the whole team could agree on something and the only thing we agreed upon was that the current setup didn’t work. One usual comment that popped up in retrospectives was “I want to do stuff, now I just work for 10 minutes per hour, then I watch other people work” and similarily “I learn new stuff best when I can try it myself, I don’t learn watching others”. Of course, you could argue that people should be just as active when not being the driver but on the other hand, it is a fact that people learn in different ways and that is something we must accept.
We experimented a lot, but mostly it was like using duct tape and glue to repair a broken car. It made us happier for a few days, but it was never a long term solution. It just made us perform worse most of the time.
One thing we tried was to split every day. Split into two mobs or one mob and one pair. A few people in the team liked this setup, but for me, it made it even worse. Now we still had the potential drawbacks of a mob but lacked much of the benefits since the syncing issues where back. Suddenly we needed to think about sharing knowledge between team members, we needed to merge code and we lacked each other’s input and special competence.
Another quite big issue we had were the long discussions. We could easily spend more time discussing different solutions than it would take to build all of them. I usually think that discussions are a good thing but this time it got out of hand. We tried different ways to solve this and one thing we decided was to vote. Vote and go with the majority. This sounded like a fair solution but the problem was that since we also split the team in different constellations each day the voting often ended in opposite directions each day making us rewriting yesterday solutions.
As you might have noted this was not a healthy team and not a sustainable way forward. I do not think that the real issue here was the Mob Programming but the health of the team. I believe that we lacked trust, people wanted to prove themselves instead of focusing on the progress of the team and we weren’t honest toward each other. In a traditional “every developer works at their own task”-team these kinds of issues would probably go more or less unnoticed. But in a mob team, problems are lifted to the surface and made extremely visible and sometimes also very painful. Looking in the mirror I believe that we shouldn’t have tried to fix the mob, the long term solution would have been to fix the team.
The kid
A few months ago I did a workshop for a customer regarding competence sharing and how to grow the learning culture within the company. One part of the workshop was a hands-on exercise where we tried Mob Programming. Since the room was filled with people from different backgrounds, like developers, project leaders, managers and testers, we used a “think like a programmer game” as the programming tool instead of using an actual programming language. That was the only difference compared to traditional mob programming. Otherwise, we followed the standard Mob Programming setup.
But there was one more unusual thing, one participant had brought her kid to the workshop. He was probably around 11-12 years old and he looked pretty bored most of the time, watching a movie on his Ipad. But when it was time for the Mob Programming session he left the Ipad behind and joined. This was such a cool experience. After 15 minutes this kid, half the size and one third the age of the others discussed solutions, proposing ideas, contributed and helped sharp professional programmers with the problem-solving. For me this showed the true power of the mob where everyone can make a difference, everyone can learn from each other and everyone can contribute in their own special way.
Conclusion
How can it be that I have had such different experiences working with the same technique?
The answer to that question is that it is not a technique that I have worked with, I have worked with people and people are different. It is probably that some people are a better fit for working in a mob, others in a pair, and some are probably best suited to code alone. I have also noted that a mob often works as an enhancer of the current status of the team. If the team is healthy, my experience is that a mob usually boost team performance. On the other hand, if there are problems in the team the mob amplifies those problems and until the team has solved those issues the team will probably perform worse than they would have done working in pairs or alone.
