Mob Programming — because, sure wasn’t pairing such great craic.

I tried pairing, I tried to like it, but it just isn’t my cup of tea. I know others on my team feel the same way. Granted we didn’t fully commit to it and perhaps we’ve set ourselves up for failure but that’s an argument for another day.

Background

I work on a team with 5 other developers. Two developers are new to the team.

Restructuring has meant our developer role encompasses an awful lot more than before. Where we once dipped our toes in the water of requirements and automated testing, we now are wholly responsible. Our team is now half the size it was, with the same amount of work to complete.

Over the last 18 months we had become very siloed, resulting in each developer having obvious gaps in their knowledge.

Mob Programming

I stumbled across some material on mob programming about a month ago, and it piqued my interest. I continued to read articles and watch videos from the likes of Woody Zuill. It sounded like a good way to eradicate the silo problem we had, and a great way to get the new team members ramped up. In the new development landscape we’d found ourselves in, we would need to work well as a team and what better way?

In short, Mob Programming is the technique of the entire team (PO included if necessary) working together on a story until it is completed. It is essentially pair programming but with more people.

Day 1

We set up our workstation as follows:

• Duplicated monitors (either side of desk so everyone had a clear view)
• A large screen (out of shot) also displaying. This meant anyone else could have a glance, e.g other team members not actively involved.
• Two keyboards and mice (to make transitioning a little easier).
• A timer screen. We used a neat timer — Rabble, that allows you to enter each developer and the time of each cycle.

There was 4 of us directly mobbing, with our test engineer validating the existing tests around the functionality. We spent the day on one story, starting out on requirements, getting clarification from the business, code analysis and then making the code changes

We worked in 12 minute cycles, and in total spent 3 to 4 hours at it. The rest of the time was taken up by meetings, lunch etc.

What worked well?

• 12 minute cycles of each driver kept everyone’s attention. The short cycle time meant that in the scenario where a meeting finished up early, we could quickly squeeze in a cycle before the next.
• It wasn’t called out, but phones stayed in pockets and other distractions were minimal
• People were able to nip away to the toilet, to quickly speak to someone else etc and the work kept going.
• Two to three of us were working on functionality that was new to us and we were able to learn whilst still maintaining a good pace.
• Lots of ideas and discussions going on.

What challenges were there?

• Different computer setup. We were using my computer and mouse. Little differences like screen setup, mouse speed etc was a little distracting for others. Not a major issue.
• I found myself pointing at the screen to direct the driver, but pointing at the screen they were not looking at. Took a while to get used to this. Again not a major issue.
• Was a relatively slow start as we found our feet, but by the end of the day we were all comfortable with the process.

Other observations

• Driver and navigator rotate. However, as some of us were new to the functionality our navigation ability was hampered. As a result we had multiple navigators which worked ok, but could be an issue in the future with multiple back seat drivers.
• Standing rather than sitting seemed to work better. Apart from anything it made transition easier.
• Our workstation setup worked well, but there may be other options worth exploring.
• Tea breaks — just have to go with group consensus with regard to when to have them. The Rabble timer allowed you to set a break every X number of cycles but we didn’t really stick to that.

Overall it was a pretty positive outcome after the first day. I think everyone saw a benefit.