What We Can Learn From Mob Programming

Originally published Dec, 12, 2017

First, full disclosure. I have never used or even seen mob programming.  When its creator, Woody Zuill, first mentioned it to me I was intrigued but wasn’t sure it would work efficiently. But, knowing Woody, I didn’t doubt it worked. Just figured only for small, independent teams.  After talking to him recently I have changed my mind. This blog is my understanding of mob-programming now, inspired by Woody’s insights. Attribute anything valuable about mob-programming to Woody, anything incorrect to me.

The question for me about mob programming has always been – how big can you go with it?  I have known that paired programming was good (having done that).  Of course, people ask the same thing about that as well – how can two people doing the same thing be effective?  Of course, that’s a misunderstanding – they are not doing the same thing – they are working together. So, we already know that micro-mob programming (a mob of 2) works.  But what’s the upper limit?  How would you discover that?

In the conversation I just had Woody told me:

With some questions it’s very useful to identify an “opposite” question.  This can lead us to finding more meaningful questions. He said the first question he was ever asked while speaking about Mob Programming was “how can you be productive with five people sitting at one computer?“

The reverse question he came up with was “how can we be productive if we separate the people who should be working together?“ The purpose of asking the reverse question is to show that there are more possibilities in the questions we could ask, and in particular when the original question is not easily answerable. This led him to a slightly better question, which is “What are the things that destroy productivity?”   And of course, productivity is probably not a good thing to strive for, and he usually prefers to talk about effectiveness.

So what destroys productivity (or effectiveness)?

  1. Hand-offs
  2. Waiting
  3. Meetings
  4. Unfinished code that you’re not actively working on
  5. Unclear understanding between team members
  6. Delayed feedback on errors you’ve made
  7. Integration problems

There are probably other things not listed. Woody tells me these things don’t happen when you do mob programming.  While I have not seen it, I believe this to be true because Woody is a very trusted source whose only agenda is helping people. It also makes total sense when I stop to think about it.  Furthermore, when I look at teams whose individuals don’t work together I see these things taking up about 80% of their capacity. So even if mob-programming is a bit less efficient because of more people working together than is needed, the elimination of 80% of what teams normally do probably more than compensates for that.  It also produces higher quality code and a broader understanding of how it was built – meaning the team won’t run into the constraint of only one person knowing how it was written.

So how many is too many? I like the observation – “In theory, theory and practice are the same, but in practice they are different.”  So I’m not looking for a theoretical limit.  The real question is when are people not contributing?  Contributing doesn’t mean just doing the work but includes learning since that, as we mentioned, improves the people and the organization. Woody, of course, has thought this through. This is one of the great things about him – he’s not trying to promote or defend anything – he’s just looking for what works. So, the solution is easy – just people the option of self-selecting out when they feel they are not making a contribution. They will still be close by when needed.

There is another aspect to mob programming.  It sounds like fun.  So give it a try and pick a number you feel comfortable with.  Then try a little bigger (remember, people can self-select out).  Having fun has clear personal value, but also clear business value.

Al Shalloway
CEO, Net Objectives

Postscript: I talked to Woody at the Deliver Agile conference in Nashville this week. Here’s another point on mob-programming. It’s all about flow and true value delivery. When I consider that most organizations are running at around 5% efficiency (not a typo – five per cent) then mob-programming, even if it were a slight waste with 5 folks around at once, would be a massive improvement).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.