Mob Programming: a first-hand look
On Thursday 29th November, the SOS scrum team decided as everyone from the team was in Zurich, that it would be a great idea to do a mob programming session.
Mob programming is, in simple terms:
"a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.”
The Amazee Labs SOS scrum team decided to take advantage of the fact that our distributed team was all in Zurich together and do a mob programming session.
The first part was to select a task that was not too complex and something that everyone could contribute to. This was decided well before the Mob so the team could familiarise themselves with the task at hand. We decided to work on a feature which allows the end-user to re-order various frontend widgets using Vue.JS, GraphQL mutations, and Drupal 8. Each of us needed to have a keyboard configuration, that we were all familiar with, installed on the Mob laptop as well as the environment to be set up for the task.
Before starting, we outlined some of the basic ground rules for Mob Programming. Mob Programming exposes your weaknesses, and it can feel very intimidating, thus there are three simple rules to help everyone feel safe and productive. Always treat each other with:
- Consideration, and
We decided to follow Llewellyn Falco's approach to using the “Driver/Navigator” pattern in which he states:
“For an idea to go from your head into the computer, it MUST go through someone else’s hands.”
Basically, the driver sits at the keyboard and types the code while the navigator discusses the idea being coded and guides the Driver in creating the code. The navigator can also get help from the rest of the mob team.
As a navigator, we must try to adapt our way of talking by following the “Intention, location, and details” pattern. Intention states what we want at the highest level. Location is about where the driver should go in order to achieve the desired result. Details are about the individual commands or key presses that might be required to perform in order to reach the result.
Intention: Sync the production database Location: On the terminal, go into the Docker container Details: Type drush sql-sync @prod default -d -v
It was decided that rotations of two minutes and twenty-five seconds would be best to ensure that everyone in the team would get enough time to be a Driver on more than one occasion. After the first hour, we had a short break, then continued on the task but increased the interval to two minutes and thirty-five-second rotations.
It took a few rotations before the team was in sync but one thing I noticed and mentioned was that we refactored the code a lot. We made changes to many files, most of which were removed at the end of the session. But, in the end, the code was much better and we even completed the task we were set. On top of that, the linter and tests showed green at the end of the session. Way to go team!
The last ten minutes were dedicated to a quick retrospective of the session. We were asked what we liked and disliked about the session.
The things people enjoyed about the mob programming session were:
- Working with GraphQL.
- Completing the task in time.
- Seeing that Lint was green.
- The amount of teamwork.
- Development flow increasing as we became more in sync.
- Having fun (it felt like playing musical chairs).
- Seeing how each individual works to tackle the task in hand.
- Exploring areas you might not be comfortable with.
The negatives of the session were
- The difficulty of working on one laptop because of personalised settings.
- Team members familiar with the Windows or Linux setup were not familiar with Mac shortcuts.
- The order of the mob was mostly the same throughout and could have been changed more.
Overall it was clear that the team had a lot of fun and learned a lot during the mob session. Some key learnings of the session were:
- Attention is key. Staying focused was easier because we moved around a lot.
- Spend the time on one task. Once we were in sync with one main task it became easier to progress.
- Learn from each other. This was a great way to have a look into the team dynamics; we learned shortcuts from other team members.
- Know-how is shared quite easily. Frontend-focused developers learned backend related knowledge.
- Share learnings afterwards. A quick retrospective helped to fine-tune what could be improved upon for the next mob session.
If you would like to learn more about mob programming, Cucumber.io have a great article about the inclusive benefits of mob programming.