At a recent Dev Ops conference, I heard the term mob programming for the first time. There do not appear to be too many people doing this around Dublin at the moment, so I was intrigued.

The basic concept is an extension of pair programming to a wider number of developers. In pair programming, two developers share the same screen, keyboard, and mouse to develop one thing at a time. By regularly swapping control from one developer to the other the pace of change can be quite high.

One of the main benefits of pair programming is that the second pair of eyes acts as a bug finder. Often simply pointing out obvious things that a compiler might catch anyway, but regularly catching bigger issues. Could a mob increase the chances of bug free code?

Spotting problems early is a key. The longer it takes to find a bug, the larger the cost. For example, catching a bug in QA is cheaper than finding it later in user testing or in production. You can’t get much faster than catching it almost as it is typed.

There is a cost involved. With pair programming, you have two developers sitting there working on one task. This means that you estimates will look funny unless they are adjusted.

We have been using pair programming for about six months and the impact on quality has been high. Also my team enjoy the interaction and the sense of a shared goal achieved.

Some of the positive side effects you get are better naming of variables, methods and classes, the developers remember to think of writing the tests first, the code is checked in regularly, tasks are broken down into smaller chunks which flow more easily, and many more other intangible positive side effects.

Pair programming reduces the amount of work in progress, or WIP. Why is this good? Effectively there is a correlation between how long it takes to get a piece of development fully completed and the team’s WIP rate. I’ll devote a post to this as soon as I wrap my head around it. For more information read The Phoenix Project.

We began gradually, dipping a toe into pair programming here and there, focusing on the areas where we needed to expand technical expertise. If one team member was an expert in a particular type of work, they paired with someone less skilled, and this helped to transfer the knowledge and expertise to the other developer.

We extended this when the feedback was that in pairs, less time was spent in code review due to the higher quality of the code. The majority of the issues were dealt with at source, and there was less code churn.

There were also less mistakes when reading and interpreting requirements and conditions of satisfaction. When two developers who are working on a task have a disagreement about what they are supposed to do, they can discuss and come to a resolution by asking the stakeholders. Better to sort it out before going to far. Pair programming helped to identify ambiguous requirements before time was wasted developing the wrong thing.

The Mob

When I mentioned the term mob programming to the team and asked them whether they would like to try it, everyone agreed that it was worth a trial run. We would try to measure whether the trade off was worth it. Was having four developers concentrating on one task at a time worth the cost of tying them up?

So far so good, especially in this most recent sprint. But we have noticed a few things that we did wrong.

At first we were tentative about this, only “mobbing” certain tasks, ones that were ready to be started when three or four of us were gathered. What do you do when you are in the office alone? Should you start the next development task or wait until a mob can form?

Starting work without waiting for others can lead you right back to the single developer, single task; developers don’t want to simply wait, they want to get stuck in.

We also went to the other extreme, spending almost every contact hour working in a mob. This is exhausting and can cause fatigue and burn out. All developers are a little bit introverted, I think, and need that time alone.

The best way to use mob programming is to regularly switch the person driving. This keeps people stimulated and concentrated. You need to know what’s going on in case you might need to run things next. However, when the mob gets a little stuck with something, time can drag on and you find that you’ve spent the entire session at one desk.

Some tasks are trivial and may get done within a few minutes. That is, before the mob can switch desks. It almost seems like it is not worth forming for these tasks. Who really has the right to decide that? Sometimes trivial tasks remain trivial, and other times they develop complications. It is difficult to know up front. My feeling is that it is better to stick with a mob for all the tasks or none on a story.

There can be a tendency to allow the person with the most experience in the given field to lead the mob, getting the work done faster, however, this sometimes makes it harder to pick up on what has been done. You get experience by doing, not by watching. Also, there is less chance of spotting issues if everyone can’t follow along.

Whether to use a single computer or use screen sharing has been a problem. Screen sharing worked well but there was a disconnection — it is not normal to talk to someone behind or to your side you without turning your head. An issue with sharing one screen is that those around you may not appreciate the constant mob.

In general we are enjoying this new technique. For example, this week three of us were learning how to use Powershell, taking guidance from the team member who had the most experience with it. On Friday afternoon, our expert had left on a half day. While the remaining mob struggled for a while, we got the task done, and all three of us left the office with a sense of completion of a job well done.

If one of us had tried the task alone, I’m certain that it would not have been completed, and would have remained so until our expert returned on Monday. We have all gained valuable experience and gotten a task done.

We have had to learn as we go, figuring out how best to approach the forming of a mob. Here are some tips we picked up along the way.

Tips

Schedule sessions

You need to plan to make sure that the team all has time to take part. Try to avoid meeting requests, interruptions, and checking email during the window. In fact, why not put a regular meeting into the calendar for all team members to block off this time?

Most of our team gets to the office by 8:30 and our daily stand-up is scheduled for 9:45, so we try to get a session of mob programming done during this window. There will generally be no meeting requests this early in the day and it is a good chance to get work done when everyone is at the highest energy levels.

Take breaks

Do plan for breaks to get a coffee or simply stretch your legs for a few minutes. Try to avoid doing other work during this time, even mindless tasks such as checking email. The idea is to allow your brain to disconnect and give your subconscious space to solve any of the problems you were addressing.

We have not found the ideal interval to use. Probably thirty minutes is a good enough chunk of time in which you can get something done before taking a break. We don’t stick to any particular timings yet, but we try to get to a commit point before breaking up.

Commit Regularly

One nice positive is that when the mob makes progress, we commit immediately and review the change. This keeps the reviews nice and small and helps us to keep making small, consistent progress towards are goal.

Swap regularly

It should go without saying that you have to regularly swap who has control. This is a pressure position to be in, with several people giving commands, all at once, and not always with the same instruction. You need to give the driver a break every now and them.

Also, if you are simply a passenger, watching but not contributing, then you are adding nothing and not gaining anything. In some cases this can be because the developer is junior or less experienced, but that’s all the more reason to give them a regular opportunity to be actively involved, at the keyboard and mouse.

Discuss whether a task is fit for mob programming at planning

You may find that some types of task are suitable for mob programming but others are not. Discuss this at planning and document it in the story or task, perhaps with a label. That way people know which tasks are suitable for individual work when the rest of the mob are not free. It takes some experience to figure out what tasks suit your mob, so try mobbing at least once on each type.

Ensure your sprint has non-mob tasks

You cannot and should not mob all the time. Team members have other things besides the story to deal with; every company has it’s share of administration, objective setting, mandatory training etc., and Scrum has many rituals that will take up time. Stories need preparatory work and production systems need maintenance.

These extra bits of work tend to fall in an unbalanced way upon team members, so there will be times when only one or two people can work actively on sprint tasks. Make sure that there is something small that they can do so that the main work, the work for the mob, remains to be completed when the mob gets back together.

Future Improvements

We have mostly been sitting around a single desk to make changes. This is the default since screen sharing was a little disappointing but we have not given up on it. Space is limited around the desks, and our area is shared with non-mobbing people (thankfully they don’t mind our mob, or at least have not complained yet). While we are all based in the office, occasionally individual members operate remotely. We will need to figure out how best to manage mob programming in this scenario.

Shared on-line environments are another possibility, however, we are reluctant to trial these without running it by our security folks. Our company is only beginning to work in the cloud so there may still be restrictions on what we can do here.

Have you tried mob programming? Let me know what you think of it at [email protected].

Do you want to give it a try? It won’t suit all teams nor all types of development, but it is worth trying out. I’ll summarise some of the main benefits and how you might get started:

• Transfer knowledge from experts to junior members
• Limits the amount of work in progress
• Better quality
• Less churn
• Faster reviews
• Sense of shared ownership and achievement

Actions

1. Pick a user story to trial mob programming on. For starters, begin with something of a small to medium size, that has about four or five technical tasks.
2. Agree to only work on the tasks in the story when a mob has formed. This should be at least three people.
3. Schedule a regular time for mob programming. Stick to this time. Take regular breaks as well as shifting who is in control.
4. Use screen sharing, Skype, book a meeting room, or simply sit around one desk.