How collective crowd programming habits can be the breeding ground for increasing technical quality

Mob programming can help teams turn old habits into effective new ones to create products in an agile way. Habits developed collectively are hard to forget when you have other people around you. Crowd programming forces people to practice new habits on a regular basis, which makes them easier to adopt. Teams don’t tolerate repetition and are always looking for better ways to do their jobs.

Chris Lucian, Director of Software Development at Hunter Industries, spoke about improving technical quality with mob programming and collective habits at Agile 2021.

Improving habits came naturally with mob programming, as Lucian explained:

While working with several people on the same computer at the same time, you have a sort of accountability group. Naturally, you start to break down bad habits and instill good ones just because the feedback loop is constantly available.

When a new group of people get together for the first time and start laughing, there are all kinds of helpful suggestions going around. Lucien gave an example:

Someone might not know the IDE and start to format the code manually. If this developer was on their own, they would probably perform this task a few times before finding the auto-format command. In a crowd, that person is reminded of the auto formatting feature every time they do the manual formatting.

This is the case even though everyone is new to the IDE, one person can browse, another drive, and someone can search. The researcher can find the auto-format key and notify the team.

In these examples, it’s easy to see how the improvements fit naturally into the system for the whole team, Lucian explained. Since everyone has different experiences and preferences, you get the best of the combination of habits and people start to share habits with each other, he said.

Lucian mentioned another big side effect of mobbing where the team becomes intolerant of repetition:

Micro-automations such as model building, auto-formatting, linting, right up to code generation based on database schemas, become the way to get the job done, not something you learn outside of it. work.

InfoQ interviewed Chris Lucian about how crowd programming and collective habits helped them improve.

InfoQ: How did you develop collective habits while doing mob programming?

Chris Lucien: When we started mobbing, we immediately saw inefficiencies: every little problem we encountered with our process, our tools and the frameworks we were using. They have just revealed themselves.

Team members would regularly say things like “We should really rename this” or, “Let’s write a unit test for this borderline case.” After a while, all team members had picked up the good habits of their peers and eliminated. the bad people.

InfoQ: What does it take to change individual habits?

Lucien: The best way I have found to change my individual habits without outside help 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 the physical locations I return to regularly, and I see the note to take action. Eventually it becomes automatic and I can get rid of the reminder or the note.

The only big problem with all of this is that I don’t have any feedback on my habits. It may take me months to realize that I need to change a habit. Sometimes I’ll ask people around me what habits I could improve, but they often lack context.

InfoQ: Can you give some examples of habits that have helped your team eliminate bugs in production? How did you get into these habits?

Lucien: The following habits have appeared in our system over the past 10 years of iteration.

In 2011, the team started doing retrospectives and learning sessions, but they still worked solo and came out about once every 1.5 years.

After we started mobbing, we started with the micro-automations I described earlier, but a great thing happened. We had learned unit testing outside of our normal job and as a crowd chose to try unit testing in our production code for the first time. Then we stayed in the habit because someone reminded the team to write one, and it was a different person every time.

In 2012, we had moved on to full unit testing and had a manual regression that brought our cycle time down to two weeks. In 2012, our unit tests increased to the point where we could publish daily.

In 2014, we incorporated automated smoke tests, which allows us to achieve approximately every half day.

In 2015, we started to grow the team. We have gradually migrated to the test pyramid with production versions of around seven mobs 14 or more times per day.

During this period, we incorporated infrastructure as code, continuous integration, continuous delivery, continuous database delivery, refactoring into models, clean code, etc. These elements were brought in during learning sessions and retrospectives kept them in the process.

Mobbing made sure that we didn’t 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 the change in habits? What benefits has it brought?

Lucien: Our cycle time has been reduced from several years to a few hours, the team’s tolerance for designing their habits has increased considerably and the happiness of our team has increased considerably.

It’s easy to fall into the status quo and iteration over habits slows down. This is not the case when you have a group of people with you. The desire to become better never stops because there is always a sounding board.

InfoQ: What did you learn?

Lucien: I started to think about the 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 understand why our habits were changing so quickly.

I also really enjoyed the “Checklist Manifesto” which gave me an idea of ​​how the team could overcome anything they forgot at a micro level. Habits naturally formed and dissipated as needed, and harassment allowed that flow to happen.

I think any team can achieve these results if they put in place the “virtuous loop” which is the combination of dedicated learning time and looking back. Learning sessions ensure that new ideas fit into your system, and retrospectives ensure that change and experimentation happens. The Virtuous Loop is the cycle of improvement and learning!

About Mariel Baker

Check Also

Minimalist movement on the BBC as it halves original artistic programming

The BBC has cut its original artistic programming in half over the past decade, as …