Mob programming can support teams in changing old habits into new effective habits for creating products in an agile way. Collectively-developed habits are hard to forget when you have other people around. Mob programming forces individuals to put new habits into practice regularly, making them easier to adopt. Teams are intolerant of repetition, and are always looking for better ways of doing their work.
Chris Lucian, the director of software development at Hunter Industries, spoke about improving technical quality with mob programming and collective habits at Agile 2021.
Improvement in habits came naturally with mob programming, as Lucian explained:
While working with multiple people at the same computer at the same time, you have a sort of accountability group. Naturally, you start to eliminate bad habits and instill good ones simply because the feedback loop is constantly available.
When a new group of people gets together for the first time and starts mobbing, there are all kinds of helpful suggestions that go around. Lucian gave an example:
Someone may be unfamiliar with the IDE and they may manually start formatting the code. If that developer was alone, they probably would complete that task many times before finding the auto-format command. In a mob, that person gets reminded of the auto-format feature every single time they go to format manually.
This is the case even if everyone is new to the IDE, one person may be navigating, another driving, and someone may be researching. The researcher may find the auto-format key and tell the team.
In these examples it is easy to see how improvements naturally make it into the system for the entire team, Lucian explained. Since everyone has different experiences and preferences, you get the best of the combination of habits, and people begin to share habits with each other, he said.
Lucian mentioned another great side effect of mobbing where the team becomes intolerant of repetition:
Micro automations like templating, auto-formatting, linting, all the way to code generation based on database schemas becomes the way to do the work, not something you learn about while away from the work.
InfoQ interviewed Chris Lucian about how mob programming and collective habits has helped them improve.
InfoQ: How did you develop collective habits while doing mob programming?
Chris Lucian: When we first started mobbing, we could see inefficiencies right away: every little problem we had with our process, our tools, and frameworks we used. They just revealed themselves.
People on the team would regularly say things like, "We really should rename that" or, &quo;Let’s write a unit test for this edge case". After a while everyone on the team had picked up the good habits of their peers and eliminated the bad ones.
InfoQ: What does it take to change individual habits?
Lucian: The best way I have found to change my individual habits without support from the outside is to create reminders in the systems I use. I keep a personal Kanban in Trello; I use an app called "Real Habits Daily" and I place sticky notes on physical locations I return to regularly, and I see the note to do an action. Eventually it becomes automatic, and I can get rid of the reminder or note.
The one giant problem with all this is that I have no feedback on my habits. It may take me months to realize I need to change a habit. At times I will ask people around me which habits I could improve on, but they often lack the context.
InfoQ: Can give some examples of the habits that have helped your team to bring down bugs in production? How did you come up with these habits?
Lucian: The following habits made it into our system over the last 10 years of iterating.
In 2011 the team began doing retrospectives and learning sessions, but they were still working solo and releasing about once every 1.5 years.
After we began mobbing, we started with the micro automations I described before, but an awesome thing happened. We had been learning about unit tests outside of our normal work and as a mob we chose to try unit testing in our production code for the first time. Then we kept the habit because someone would remind the team to write one, and it was a different person every time.
By 2012 we had moved to full unit testing and had some manual regression which brought our cycle time down to two weeks. In 2012, our unit tests grew to the point where we could release daily.
In 2014 we incorporated automated smoke testing, allowing us to get to about every half day.
In 2015 we started to scale the team. We gradually migrated to the testing pyramid with releases to production from about seven mobs 14 or more times a day.
Over that time, we incorporated infrastructure as code, continuous integration, continuous delivery, database continuous delivery, refactoring to patterns, clean code etc. These were brought in through learning sessions and retrospectives kept them in the process.
Mobbing made sure we did not forget to do it before it became a real habit. Now no one needs a reminder to do these things.
InfoQ: What has been the impact of changing habits? What benefits has it brought?
Lucian: Our cycle time went from years to hours, the team’s tolerance for designing their habits went way up, and our team happiness increased dramatically.
It is easy to fall into the status quo and iteration on habits slows down. This is not the case when you have a group of people with you. The drive to become better never leaves because there is always a sounding board.
InfoQ: What have you learned?
Lucian: I started thinking about habits in relation to the team and the dynamics of mobbing after reading the books "Power of Habit" and "Atomic Habits". I think both books helped me see why our habits were changing so rapidly.
I also really enjoyed the "Checklist Manifesto" which gave me an idea of how the team could get past anything they were forgetting from a micro level. Habits naturally formed and dissipated as they were needed, and mobbing allowed for that flow to happen.
I think any team can get these results if they put the "Virtuous Loop" in place, which is the combination of dedicated learning time and retrospectives. Learning sessions ensure that new ideas make it into your system, and retrospectives ensure that change and experimentation happens. The Virtuous Loop is the cycle of improvements and learning!
