Mob programming – full team, full throttle
codebetter.com/marcushammarberg/2013/08/06/mob-programming/
By Marcus Hammarberg August 6, 2013
One of the things that fascinates me with our industry is that you can learn new stuff, things that throw your
current ideas on end and even provokes you – every day. For my first blog post here I thought I share such a
concept that have surfaced to my mind the last couple of months.
Being offered to blog for CodeBetter was nothing I expected and I’m deeply humbled, a bit proud and somewhat
nervous. So I thought the best way of handle those feelings was to just write about something that provoked me a
lot when I first learned about it, and probably will provoke you too. This way we get to know each other, I
thought :).
In this post we’ll take a look at mob programming – a concept that made me ask the same questions that I have
had to answer for agile practices that we take for granted today, like pair programming and limiting work in
process. The post has two parts; first I’ll quickly introduce the concept of mob programming and then have a
little discussions on the implications of using it. Hopefully provoke you a bit in the process and maybe tempt you
to try it out.
But beware: mob programming is only for those that really want to deliver stuff really, really fast. And with the
highest quality possible. The rest of us cannot handle it.
Mob programming – what is it?
From http://mobprogramming.org/ (c) Andrea Zuill
The basic concept of mob programming is simple: the entire team works as a team together on one task at the
time. That is: one team – one (active) keyboard – one screen (projector of course). It’s just like doing full-team
pair programming.
Just as in pair programming you have a driver that uses the keyboard and focus on the details (writing the code,
following our coding standards etc.) and the rest of the team acts like navigators that focus on the higher levels
(are we solving the right problem, what’s next etc.) as well as helping the driver when needed.
As in pair programming we rotate drivers on a regular basis. There’s different strategies for this; ping-pong-
pairing means that you write a failing test and then pass the keyboard over to the next person that fulfills that
test and writes a new failing one before returning the keyboard. That might not be feasible for your team mob so
1/3
then you can use a timer to manage the rotation. Every 15-20 minutes for example. Find an interval that works
for your mob and experiment to refine it.
There’s more to tell and subtleties to mob programming but that’s better told by the man that came up with the
concept Woody Zuill over that the mob programming web site. Actually – there’s not very much more that you
need to get going. Here’s a time lapse video that shows a team doing 8 hours of mob programming (takes about
4 minutes to watch) that shows mob programming in action.
Mob programming – why is it interesting?
At this point you probably have a lot of questions and some of you, like I did the first time I learned about it,
grew angry and said: that’s simply not efficient!
Let’s answer that argument in two steps. Not it’s not efficient… if you’re into the business of having maximzing
the number of keystrokes per developer. But if you’re into delivering fully working features with the shortest
possible lead time, well then there’s actually no quicker way.
Lead times
Let me clarify what I mean. Imagine that we have a team with all the resources needed to take a feature from
idea to production. We have developers, testers, BA’s and designers. We’re using continuous delivery and can
push to production as often as we like. When this team works with one single feature, that feature moves from
idea to production (what Lean-folks call lead time) at maximum speed.
For every question that pops up, there’s someone ready to answer. We don’t have to wait for anyone to come into
the room to solve it. Everything that comes up can be answered and dealt with immediately, we don’t have to
stop one line of thought and “come back to it later”. We just do it. Now.
“But, but … that means that a lot of people is sitting around … not typing” – I said around this point. Yes – that’s
exactly what it mean. But you’re not in the keystroke / minute business, now are you?
Have you been waiting at the emergency? You know what I mean; you’ve been sitting there for hours upon hours
when all of a sudden a real emergency happens: the ambulance comes with someone that doesn’t breathes. That
poor person (it went well, no worries – I just made it up) just flies through the ER and gets treated in seconds.
What’s the difference in how the ER staff acts? For normal, non-urgent cases, hospitals often try to make sure
that the staff is kept busy, especially those expensive doctors. In fact, at least in Sweden, the hospitals are so
scared of doctors ending up idle, that queues of waiting patients are built in front of them. When the emergency
occurs everyone (almost) drop what they are doing and rush to the ER. There’s an abundance of staff around the
stretcher, until the patient is stable. In the latter case the lead time of the patient is critical and so we value short
lead time over maximizing staff utilization.
I better stop the ER/Hospital analogy here since it gets political around this point and I’m not into that.
So, what is critical for us? Staff utilization, keystrokes per minute, lines of code per minute or moving features
fast through our process into production? That’s shouldn’t be hard to answer in most cases.
“The man in the mirror”-argument
The other thing that made me take a good stare at myself was that I was lining up the same arguments against
mob programming like the ones that I have had to answer over the years when it comes to pair programming.
“but, that cannot be effective?”
“so every other programmer will just sit around doing nothing?”
“do you have any studies that shows that this is superior?”
2/3
These are questions that I haven’t been able to answer and therefor have asked stakeholders to put trust us in.
Now that I’m introduced to a new concept I’m questioning it in the same way. Where’s the trust now? Where’s
my sense of “try it”? Shame on me.
Finally I’ve seen mob programming in action, tried it a couple of times and knows that it works. One of those
episodes was at my current client. One team had started to work on a major change in the domain model. I’m
talking real foundational stuff – like introducing the concept of a Product into a domain that was really around
products but didn’t have that concept in place today. That kind of changes thats referred to as “heart surgery”.
For a couple of weeks (months even) nothing was produced, not much new stuff was learned and they didn’t get
anyway. One day it was suggested that they lock themselves into a room for three days to “dive in an get their
hands dirty”. So they blew their schedules free and went into a room, the whole team with just one computer and
a projector (now, where have I heard this before…).
Three days later they came out with a working skeleton of the thing they were about to build. They even
demonstrated it to those interested (EVERYONE) before leaving the room.
Conclusion
I’m not saying that mob programming is for everyone, neither is pair programming. It might not be for all types
of task either – things that you just can “type” out and not think to much about is probably not suitable for mob
programming.
But I am saying that getting your team into a room, with one computer and one screen, the whole team working
together on one feature – that there is no more effective way to get that feature out.
It’s not maximum efficient when it comes to resource utilization – but we’re not in the keystrokes business,
right?
3/3
