Mob programming – full team, full throttle

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?

Mob Programming

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 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?”

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?

About Marcus Hammarberg

I am a consultant with Aptitud working with coaching on Lean and Agile thingies. Right now I'm finishing writing a book: Kanban In Action (http://bit.ly/theKanbanBook) When i am not working most of my time is taken up by the Salvation Army and playing my instrument, the euphonium. I am married to Elin since july 2006 and have three sons Albert , Arvid and Gustav
This entry was posted in agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • marcusoftnet

    Hi Neil – thanks for you comment.

    Cool – you did this way back. And you’re right. Most (good) things are built from other ideas. I’m also inclined to think that mob programming is not suitable for every line of code, but as soon as there’s thinking, designing and different approaches involved – i’d try Mob Programming first.

    That said: there’s not many work places that I’ve seen that would buy into this, so a gradual ease into full-time mob programming is probably needed. And your approach (as well as the team I described in the article) are excellent ways of doing that.

  • Neil O’Connor

    Not really a new concept, as with most things under the sun! We were doing this 10 years ago and calling it ‘full team coding’. We found it worked best for specific core framework developments where we wanted the whole team to feel a sense of ownership, and not to feel it had been imposed upon them.

  • AllianceTek

    Great post…. thanks to share with us

    http://www.alliancetek.com/

  • marcusoftnet

    Hello Kareem – thanks for you comment.

    One of the things that’s really interesting with a mob is that it natural limits the work in process to one. A single item can be worked on at the same time. Hopefully and preferable the highest prioritized work item too. When that item is done we can look over our backlog (not a big fan of that word) and see what’s most pressing now.

    And again, limiting the work in process to a single item is great for lead time (it flows optimally fast through our process) but is not so bad for our resource utilization (since not everyone has things to do). In “real life”, i.e. not software development, we find teams with WIP limits of 1 in high risk occupations. Firemen for example: we have an overcapacity of firemen, that sit around waiting for emergency, just so that they don’t have a queue of fires to put out before they can come to mine. We, the tax payers, gladly pay them for that since we don’t want to hear: “Yes… we have an opening next Tuesday” when our house is on fire.

    The hospital situation you describe above would actually be doing 5 things at once. The mob working on five work items at once. It would be devastating for our focus and that would quickly be shown in the lead times for each one of the.

    Finally, let me answer your question: the mob goes through the backlog one item at the time. In the prioritized order. Just as any other team. The big difference is that the mob only works with one item simultaneous.

    I hope this answered your question. Thanks for a great comment.

  • Kareem Sultan

    Interesting. Agreed the keyboard isn’t the bottleneck, but you didn’t cover how this is better to get through a backlog of stories. This definitely gets a single story through with minimal cycle time, but what about ten stories?
    A hospital doesn’t deal with five simultaneous emergencies one at a time.