Software development shouldn’t be an isolated island with little outside contact. However, communication between a development team and external stakeholders isn’t always easy, especially if their sole shared moments happen during sprint rituals. When themes such as transparency or communication come up in retrospectives, a team should consider incorporating new ways of knowledge sharing. One such way is mob programming.
Our development team was at a crossroads of sorts. With some new members and the departure of others, we felt the need to synchronize, since our customer has multiple products of varying maturity and technology stacks. At the same time, their own developers had begun to work more closely with us, so overall there was some confusion over how to get the most out of our team. It was in one retrospective, where communication and visibility were discussed, that a developer suggested mob programming as a possible solution. Despite none of us having tried the method before, we decided to give it a spin in the next sprint.
Working simultaneously
Mob programming extends the principles of pair programming to an entire team. In a mob session, attendees work simultaneously on the same problem, using only one computer. While the implementations of mob programming vary, at its simplest there are only three different roles: the driver, the navigator and the mobber. The driver is doing all the coding, but they should not make independent decisions. They listen to the guidance of the navigator, who in turn discusses with the mobbers. The navigator should give as detailed instructions as necessary, considering the background of the driver, while the mobbers follow the progress via big displays. All work happens in timed cycles, with the roles rotating in between. In our case, this meant that a product owner found themselves writing code, and a UX-designer pushed changes to a remote repository.
We started with our scrum master as a facilitator. He took care of the practicalities and made sure the team was committed to trying out the new method. We set up a development environment in a conference room and started working towards our goal. It was a slow start, but little by little, code started to appear. Whenever we hit an impasse, we took a breather and made sure we were heading in the right direction. At the end of the day, we had laid promising groundwork for a new feature. Satisfied with the results, we booked time for another mob session in our next sprint planning.
Exceeding expectations
In the long run, the effects of mob programming have exceeded our expectations. In addition to getting actual work done, the whole team has become closer. Everyone despite their level of expertise has learned new things about our architecture, best practices, handy IDE shortcuts and more. The sessions have been so well received, that we began doing them regularly. The whole team, the customer included, is invited. While on paper it may seem wasteful to frequently assign multiple people to work on one item, mob programming can induce widespread benefits:
- Instant communication between team members, since no time is spent waiting for answers or sending emails back and forth. Communicating face-to-face reinforces good teamwork practices and the mentality of giving and receiving help. Kindness and respect will be on the rise.
- Improved decision making. The possibility to discuss problems and pitfalls together reduces overall reluctance to make decisions. This collaboration increases the individuals’ commitment to the results.
- Reduced waste, especially if the product owner is included in the sessions. The team can get instant feedback on their progress, discarding unwanted additions.
- Improved code quality. Having more than one set of eyes reviewing the code reduces technical debt. Best practices easily spread across the team, and even previously unidentified technical debt can be recognized.
- Reduced context switching, since the whole team becomes familiar with the feature being worked on. Mob programming can also shine a light on dependencies between different parts of the software, increasing overall familiarity of the architecture.
Ultimately, mob programming is a tool I can recommend to any team, whether they’re facing issues or not. When starting out, decide the topics beforehand and get everyone up to speed with the goals. This increases commitment reduces anxiety and maximizes your time available for the actual work. Once your session is underway, make sure that people remain in their roles. Experienced developers might be tempted to drive ignoring or predicting the navigator’s instructions, a pattern that should be prevented. Once your team’s confidence grows, you can start tweaking the parameters such as the roles or timing to better suit your needs. You can also try applying this method outside programming, for example in UI-design or user story creation. Have fun firing up your own mob!
