About a year or so ago, I had the chance to go on a Hunter Industries virtual tour. Basically, I spend a day working with them. I was looking forward to this since I learned about mob programming, as that’s the place where it was born. It was amazing. I’ve had enough time to reflect on that experience, so I want to share what I believe are the most outstanding traits of that culture

Experiment on everything

I mean, EVERYTHING. The team was working on some JS code and didn’t know how to use the IDE to debug it. The reason was that they were experimenting with using that new IDE that week! They had no prior experience with it (and neither did I) so we were tumbling all along to figure out what was going on at runtime (console.Log anyone?). It was kind of frustrating. But that’s how it is when learning something new.

The main point is that nothing is written in stone. They experiment with team configurations, tooling, work organization, techniques, and everything in between. This is probably the thing I loved the most. There is not a “we do things this way here” mentality but instead a curious, open-minded one. If you have a proposal to do things a different way, the team can give it a try for a time and see how it works. I just wish more organizations were this flexible. After all, all improvement is a deviation from the standard.

Mobbing

So I just spoke about flexibility. As the place where mob programming was invented, I expected the practice to be mandatory. Certainly is the default way of work. But people can pair or go solo as needed. It’s just that flexible.

I have to be honest: the main reason I took the tour was because I wanted to learn firsthand how to do mob programming. I had tried before but it didn’t turn out as I expected. I made many mistakes while trying to implement it. Having the chance to mob with a team experienced in the practice was quite an instructive experience. It seems to me that a lot of the mistakes I made, were just deviating from the simple rules at one point or another. It’s about discipline.

Rest often

The reason we are told to hydrate continuously is not to quench thirst, but to avoid feeling thirsty in the first place. One of the practices we followed strictly was to rest for 10 minutes every 40. With one hour lunch. Even if we were in the middle of something we would stop and take a break. The end result was that I didn’t feel tired after hours of deep concentration work. It was amazing. But it did require discipline.

Rotate often

This is one of the mistakes I made in my earlier attempts. For starters, the lack of some sort of control to keep in check who was next and when. We would often get carried away and forget to rotate who was typing and who was thinking until later on. The effect of this was disengagement from some of the team members. So rotating often is actually a very important thing. We were rotating every 4-5 minutes, but it can vary depending on the team.

Cross-pollination

This is one of those things that sounds too radical to most organizations. It turns out that every so often, the team switches members for a week or so. Since the team works as a mob, getting someone up to speed is actually very fast. Heck, even I could start being productive after an hour or so given that I had never seen that codebase. This way the knowledge of the different products is spread among all the teams. Something to note as well is that no person can remain on the same team for more than 2 years. You can either switch before or at the 2-year limit.

Mini-retros

Something to take into account is the constant feedback received from the environment. You receive feedback from your peers as you bounce your ideas with them. You receive feedback from the unit tests about your code. And then we have the mini-retro at the end of the day. I didn’t expect that but it was actually very cool. One of the things we discussed was the need to learn how to set up the tool for debugging and decided to do that the next day. This was cool because I have been in similar situations before but usually, the momentum just leads me to decide to stick with whatever hack I’ve been doing, even if it’s not optimal. It’s like trying to take down a tree with a blunt axe and deciding there’s no time to sharpen it. By having a small retro at the end of the day, we allow ourselves to pause and reconsider if there are better ways to continue… to sharpen the axe.

Small teams

I was told that the average size of the teams is 4. That’s another of those practices that seem to be irrelevant at first. But as time goes on I’ve come to discover that having 4 people in a team is enough to challenge any idea and see if we can’t come with something better without getting into a deadlock of opinions. Having too many people makes reaching a consensus hard. Having too little makes it hard to have a diversity of ideas. I suspect around 4 may be the sweet spot. Coincidence? a deliberate choice? an unconscious choice? You’ll have to ask them 😉

TDD everywhere

I love TDD. I found it the most effective way to work. If you are trying to give it a try, I suggest to break everything into small tasks. So I found it refreshing to be able to work with other people this way. They we’re all seasoned practitioners and I pick up a few things from them. I believe you can go a long way just working on a mob, but bringing TDD into the scene helps to focus the attention of everyone to a single task: make the specification pass. Refactoring can happen later.

Closing words

A technically sound culture doesn’t happen by accident. It requires deliberate actions. I believe that the cornerstone of the success of the team at Hunter Industries is their relentless pursuit of a better way through constant experimentation. The disposition to try and fail and try something again, has undoubtedly shaped some of the practices metioned here. It just that this implies throwing away the current process, practices, and policies and considering that it’s human nature to fight change, I’m afraid that it will take a long time before we start to see more companies adopt these ideas.