Over the past few months, us developers on the GOV.UK Custom Formats team have been trying out a new approach to software development called mob programming.
Instead of individual developers working on stories separately, mob programming involves a group of developers working on the same story together in front of the same computer at the same time. One developer acts as a ‘driver’, typing on the computer, and everyone else acts as ‘navigators’, guiding what the driver should type.
We’re not the only team at GDS to be testing out this new approach. Verify has blogged about its own experiment with ‘mobbing’ to develop its current frontend application, and Digital Marketplace more recently shared why they used the approach to rewrite a collection of code.
We wanted to give our take on why our team began mob programming and share some of the benefits we’ve experienced, as well as what we’ve learned from the process so far.
Why we started mobbing
In April we were visited by Woody Zuill, an Agile coach who wrote an excellent book on mob programming. Woody answered our questions and concerns about the approach, and we came away thinking it could be worth testing out. There were some team circumstances that influenced this decision too.
Firstly, we had two new junior developers join the team, and mob programming seemed like a good way to introduce them both to the codebase at the same time.
Secondly, we were about to start developing a new app from scratch, and the mob approach seemed like a good way to collaborate on a project that required a lot of thought and discussion.
How we mob
We followed the same approach that we would on any other project on GOV.UK; we iterated. We started with a simple setup - a laptop plugged into a monitor and a group of us crowded round. There wasn’t much of a process defined at this point in our mob programming journey, so we would rotate navigator and driver roles through the group and take breaks when we felt like it.
Eventually we evolved to having a couple of monitors linked up to the same laptop so we could all see the code better. We also realised after some time that having a bit more structure enabled a fairer rotation of roles, so we now switch drivers every 10 minutes or so, and take a break every 3-4 driver changes.
4 benefits of mobbing
Since mob programming is getting more popular within GDS, we thought we’d share the top 4 benefits we’ve experienced incase it helps other teams experiment with the approach.
1. Our developers learn more
Everyone learns something during a mob programming session, whether it’s a cool Rails trick or a new keyboard shortcut. It’s impossible for everyone to know everything about the technology they’re using, the project they’re working on, or their development environment, so mob programming is a great forum for picking up new knowledge.
Explaining thought processes and the particulars of a certain technology also makes a great mentoring opportunity between more experienced developers and junior colleagues. In the beginning, developers were self-conscious about not knowing how to do a particular task, or not understanding everything that came up during a session. Eventually, they became more confident in expressing they were unsure of something, whether they are juniors or more experienced developers. This has ultimately improved our communication and learning.
2. Knowledge is shared across the development team
By collaborating on stories, developers have better context when picking up subsequent stories, or when a team member is absent.
3. We can move faster
During mob programming sessions, we could make decisions more quickly and more confidently because there were other people to discuss them with. There was no longer a need to arrange a separate time to chat about an issue. We didn’t need a separate code review as we had already had several pairs of eyes on the work. Additionally, when a developers had to drop out due to a commitment, work wouldn’t stall because others were able to carry on.
4. Our working environment is improved
Working with other people is fun! We even had comments from non-developer team members that they felt our mob programming sessions created a nice atmosphere, and some joined in occasionally to observe and see what it was like.
Our 8 mobbing tips
In terms of what we have learned about mob programming, there are 8 tips we can share if you also want to try it out.
1. Take regular breaks
Programming in a group requires prolonged concentration and this can leave developers feeling worn out by the end of the day. In order to prevent exhaustion, taking regular breaks throughout your session is really important.
2. Structure your sessions
To make sure everyone gets their share of the driver’s seat, and to enforce regular breaks, we needed to get a proper structure in place. We use Rabble, a mob programming timer developer by one of our colleages at GOV.UK Verify to manage our sessions.
It helps us define who is in the mob, whose turn it is to drive, how long the cycles are and when we take breaks.
We still need to experiment with our structure. It’s not yet clear what the ideal cycle time and number of cycles before a break is necessary. We need to avoid burnout and exhaustion, but we also want to be as productive as possible.
3. Smaller pieces of work are not always suitable for mobbing
Smaller stories or investigative exercises are not as suitable for mobbing as we initially thought. The idea that a team can always work as a mob was an interesting thought to begin with but ultimately larger stories which require decision making and a variety of experience are the ones that seem to be the most suitable to the approach.
4. Big mobs can get unwieldy
We’ve mostly run mobs dependant on who is available, and what work is in the pipeline, but we’re not sure yet if there’s an optimal size. Is a group of more than four too large? Does it depend on the story? Currently a group larger than five begins to feel a little unwieldy especially given the space and layout of the area used by our Custom team.
5. Consider the ideal environment for each developer
Even though you are working as a team, it’s still important to consider the preferred development setup for each individual. No two setups are the same. Some people work more productively with Vim than a text editor, and developers have their keyboards set up in different ways.
We still need to figure out how to switch between people’s preferred development setups and how to provide the ideal environment for each team member.
6. Try and create the best possible mob programming station
We’ve learnt that the more space around the monitors, the better. Our mob programming station isn’t ideal as we have lots of crowding around the monitors. We worry about getting in other team members’ way, as well as creating too much noise.
7. Hold regular retrospectives
Providing feedback and coming up with solutions helps evolve and improve ways of working. Our retrospectives quickly tell us what works and what doesn’t, even if it’s that...
8. Mob programming is not suitable for everyone
Not everyone enjoys mob programming. As a team, we need to be conscious the approach isn’t suitable for everyone. Some people prefer working solo or in pairs. We still need to ensure the work being planned is varied enough to suit people’s preferred styles.
It would be great to hear your thoughts or tips for to mobbing. Please feel free to comment below.
You can follow Emma on Twitter, sign up now for email updates from this blog or subscribe to the feed.
If this sounds like a good place to work, take a look at Working for GDS - we're usually in search of talented people to come and join the team.
