The mob rules, ok?
During the last 6 weeks or so, I've had the pleasure to be working on Cucumber
Pro with the team at Cucumber
Limited. One of the key thing making this such a good
experience has been the way we've been working. Mob Programming.
What is Mob Programming?
All the brilliant people working on the same thing, at the same time, in the
same space, and on the same computer — @woodyzuill
Mob Programming is a term coined by Woody Zuill. It describes a practice that he
and his team "discovered" while he was coaching at Hunter Industries. It's a way
of working where the whole team gather around a single computer and work on
a single problem together. The team take turns to "drive" the computer, while
the other members of the team help to think through the problem and find
A Remote Mob
The Cucumber Pro team works remotely. We are geographically distributed
(although we are usually in similar timezones). Obviously this makes sharing
a computer more of a challenge, but we've found a couple of solutions that are
working well for us.
The first thing is that the person driving always works on their computer. This
allows everyone to use the tools they are most comfortable with and saves them
from them having to deal with lag or other connection problems on input.
To share the driver's computer with the rest of the team we have mostly used
Screenhero. Screenhero allows us to share a single
computer with several other participants (I think we've had up to 5 or 6).
Unlike other screensharing technology it also gives each user a mouse pointer.
This is especially useful when trying to point out where that misspelt
variable is hiding. Screenhero also allows the navigators to type, which helps
from time to time.
While Screenhero does provide a voice channel, we generally prefer to use
Google Hangouts for voice and video. Partly
because the sound is better, but really because being able to see each other is
We haven't found a really good solution for a shared whiteboard yet. Most of the
drawing we've done has been on paper and shared with photographs. We've also
experimented with an iPEVO
camera. This lets you share
a drawing live as it happens. We've used it point to paper on the desktop, and
with a whiteboard. This is a bit more of an interactive experience, but it still
only allows one person to draw.
We decided that the Cucumber Pro mob would only convene in the mornings. This
gives us 3.5 focussed hours where we all work together. These morning mob
sessions are where we take design decisions. We discuss the work that's to be
done. Talk through the business, and find examples that we can use to
illustrate them in our Cucumber features. Its also in these sessions that we
write most of the code.
Afternoons are more free-form. For a start everyone in the team has other
responsibilities. So this leaves space for this work. Dealing with email,
running a business, open-source, etc.
But... it also leaves space for people to think, to read, to experiment, to fix
little niggles, to automate tiresome tasks. This space is invaluable. We
liberally use TODOs while we are mobbing. We use them in the same way we might
note something we want to address later on an index card. Fixing TODOs in the
afternoon has been quite common. Sometimes this is just tidying up and getting
work out of the way, so the mob can focus on bigger tasks. Sometimes this is
a spike to try out some idea before presenting it back to the mob.
We use Github's pull
requests in a couple of
different ways. Firstly, any work that people undertake outside of the mob (in
the afternoon), is almost always done on a pull-request. This allows us to use
GitHub as the communication channel about the code, and it means that work that
is done indivdually is seen by someone else before its merged.
We have also been using pull requests for work-in-progress. Not everyone on the
Cucumber Pro team is available everyday. There's often someone away delivering
training or consulting, or at a conference. Again pull requests let us use
Github's great tooling for seeing changes to the code over time, and having
asynchronous discussions with those who weren't able to join the mob.
We end every mob session with a short retrospective. We ask ourselves two
- What have we learnt?
- What puzzles us?
We use this as a chance to reflect on the work we have done, and how things
went. We try to recognise things that have gone well so we can do more of them,
and recognise problems early so that we can head them off.
We also spend a few minutes thinking about the next steps, where the mob's focus
should go next.
We write all of this up in a file at the root of the project and commit it to
the repository. This is helpful for the team members that weren't in the mob
session. It helps to share what we've learnt and our questions with them. It
also marks where the mob finished that day.
We're currently adding each retrospective at the top of a single file, and
maintaining a history. I'm confident that it will be useful to reflect back on
how our thoughts and feelings about the project change over time.
Mob programming is a great way to build a team. I feel that we get a real sense
that we're working together towards a common goal. We solve problems together.
We learn together and we teach each other. By reflecting on each session, we
learn more about how each of us likes to work, and how we can all help each
The remote working lets us all be comfortable in our surroundings. We've had
Matt join for a few hours while he's been in
Australia. The last couple
of days Aslak has been in the mob, with
his new baby nestled in a sling — there is something really calming about
hearing contented baby gurgles while your working.
Remote collaboration is quite an intense way to work. I've done quite a lot of
remote pair programming and it can be quite draining. Keeping the afternoons
free really helps to combat this.
Working in the mob everyday is fantastic. I look forward to them because
fun, and I feel like we're growing as a team every day — but the afternoon
space is just as important.
This article was originally published here.