Mob programming can be done remotely. At Cucumber this is achieved by using a cycle in which the driver pulls down the latest code and then shares their screen, the team mobs for 10 minutes or so and commits the code. Next, the driver’s role rotates. "Remote mobbing works really well for me", says Sal Freudenberg, "because it lets me tailor my working environment and work in a spot where I feel comfortable."
Sal Freudenberg will give a keynote about remote mobbing at European Testing Conference 2019. This conference will be held February 14-15 in Valencia, Spain:
This conference is about getting experts and practitioners together to talk, learn and practice the art of testing. We’re looking into advanced new methods into making our testing more effective, as well as enrich our understanding of fundamental methods to grow a stronger community.
InfoQ interviewed Freudenberg about her experiences with remote mob programming.
InfoQ: How does remote mobbing work?
Sal Freudenberg: There are typically between three and five of us on the remote mob (although sometimes we just pair). We each take turns to drive, with a preference for the driver being the person with the most to learn / the least idea on what to do next. We look at our yak map (A term I think Steve Tooke may have made up as it stops us shaving yaks) to see where we are up to in the problem space. Then the driver pulls the latest code down onto their machine and screen shares (we use Zoom for video conferencing and screen sharing).
The whole team then problem solves together - effectively all coding - but the driver is the person who types. We try to set a timer for 10 mins, and at the end of that time, be in a position to commit code. Although sometimes we "cheat" if we are in flow, aiming for 10 mins to get to a commit keeps us pretty honest about breaking things down into micro-commits.
InfoQ: What are your experiences in mobbing remotely with the Cucumber team? What have you learned?
Freudenberg: It has made me rethink everything I thought I knew about collaborative programming and remote working, for example the idea that co-location is really the best way to "properly" collaborate. Had I not experienced it myself, I would definitely have been doubtful that it could actually work - how could people stay engaged? How could we switch roles? And yet these things have really not been a problem at all.
It’s completely fine to roll on and off the mob as and when you need to, and with relatively few "rules of engagement" - be kind, don’t butt in, write down your ideas for later rather than sharing them immediately - it is surprisingly seamless.
InfoQ: What benefits have you seen while doing remote mobbing?
Freudenberg: At first I found it a little intimidating, but it’s a great way to knowledge share. Plus, one of us is often able to take a step back. I think of myself as a bit of a "code canary" because if the code is ever obfuscated or overly complex, I kind of "faint" by putting my hand up and asking if there isn’t an easier way to express something, or whether it would be possible to use a more established solution rather than go on a yak shaving mission ourselves.
Many pairs of eyes on the code makes us come up with more elegant solutions, I think, and that still works even if one person needs to go off and investigate something. Plus if one person is saturated, then someone else is often energised.
InfoQ: Being autistic, how does remote mobbing work for you?
Freudenberg: Remote mobbing works really well for me because it lets me tailor my working environment. I can set up to work in a spot where I feel comfortable, with any props, variable lighting, my favourite chair, etc. I can turn the camera off at times if that makes me feel more comfortable - or just look at the code rather than everyone’s faces. It’s fine to roll on and off the mob as well, so it’s easier to take breaks if I feel saturated.
My favourite thing is that when we take a tea break I can turn the screen off and have some alone time, something which is much trickier in a physical office.