Mob Programming - An Experiment

What is Mob Programming?

Mob Programming is a practice where the whole team works on the same item of work. All heads are brought together to make decisions on design, quality, naming conventions, etc.

There are two roles: The Driver (person at the keyboard) and The Navigators (rest of the team)

The team should rotate in a given timeframe. Most people choose 15-20 minutes.

The team should self organize around how they want to work and for how long.

There is a good description of basic set up and how-to here:

http://mobprogramming.org/mob-programming-basics/

If you want more context and the 'why', Woody Zuill has been speaking all over the world about this practice.

Here is a talk he has given on it:

https://www.youtube.com/watch?v=8cy64qkgTyI 

What are the stated benefits of Mob Programming?

Queuing Theory suggests that the less work in process the more we can get done, with quality, which keeps the overall work queue down.

Just In Time Planning - The team works and makes decisions as a group on architecture. Decisions can be made at the team level in real time without waiting for or creating a meeting to discuss.

Small Batch Processing - Working on one small item at a time, with quality, means incremental iterations of 'done' happen more often, making for a more stable, cleaner codebase.

Quality and Code Reviews - Code reviews happen as the code is being written. With more eyes on the code, more mistakes will be caught before they are released into production.

Less Rework - Since the team is all working on one branch and checking in regularly, there is no risk of code conflicts which would result in rework.

More focus on the work, less on the people. By designating times when the work gets focus, we eliminate the variations that come from distractions, unplanned work, vacation days, etc. If one or two people are out, the code can still be worked on as the whole team should be familiar with the effort.

Increased Collaboration/Teamwork - Teams learn to work together. The format encourages all members to speak and participate. It increases shared understanding around the solution being built.

Experiment in Mob Programming

A team I was working with decided to try mob programming after doing a team code review. A member of the team had done some work on his own and presented it to the rest of the team. The team wanted to gather as a group and gain an understanding of the architecture and the work. In doing a team code review, they realized that there were a lot of conflicts with their overall schema. They realized that these problems would have been avoided if they made these decisions as a team.

They decided to try Mob Programming.

They started off with a few larger (4 hour) sessions. This felt too long, so they opted for smaller (1 hour) sessions.

Eventually they opted for one (2 hour) session in the afternoon and an informal pairing/mobbing in the morning.

Team guidelines: The team decided 20 minutes for each member at the keyboard. They each wanted to use their own laptop/system, so this required checking into a feature branch every time they switch. In this way all team members had access to the code changes in near real-time. Team members could come and go as needed/desired and were not obligated to participate. A web conference was spun up during mobbing exercises for those that would rather work remotely or from their desk.

What we learned

The first hurdle the team had to get over was having very different set ups. A lot of learning took place as team members learned best practices from other users in terms of tools and environment set up.

We had already broken our work down into small (1-3 day) efforts. We pulled the first one on the list and started working.

The team started making decisions together regarding naming structures and architecture patterns that they wanted to follow.

When the team got stuck on something such as library options, multiple team members could research until we found a suitable answer.

The team was able to collaborate on problem solving in real time. All options and perspectives could be discussed and the best option chosen by the team.

Team members were correcting typos in real time.

Team members were reminding each other to write tests first.

Bad logic was discovered as it was being written. The team was able to correct.

Switching every twenty minutes meant that the code had to be 'check in ready' regularly.

We eventually started to delineate types of work that could be done individually vs as a group. Any work that is simple and straight forward can be picked up individually. More complex work is done as a team.

Retrospective 

At our first retrospective after trying Mob Programming, the following feedback was recorded by the team:

- They felt more productive

- They enjoyed the coding discussions they had

- They learned a lot from each other

- They felt like more people had input into the architectural patterns and designs (and quieter voices were being heard)

Recommendation

Mob Programming is a great tool/way of working on new complex initiatives. If the team is not sure on architecture/direction, this style of working allows for everyone's best thinking to be present.

As the team learns and gains momentum, we intend to break out to work in parallel mobs/pairs.

It is a great tool for team building, cohesion and morale.

If your team is uncomfortable trying it, I recommend trying a group code review. In fact, I recommend spending a part of each day as a team to review team code. It's a great way to share learning and allow for socialization of the ideas/problems in the code. If/when the team breaks into two mobs, our intention is to have a shared code review at the end of each day.

Have you tried Mob Programming? What have you learned? What barriers does your team have in trying it?