Q&A on the Book Code with the Wisdom of the Crowd

The book Code with the Wisdom of the Crowd by Mark Pearl explains how mob programming can be used to collaboratively solve problems. It also provides scenarios to fine-tune and adjust the interaction during mobbing for specific situations and advice for preparing mobbing teams and developing the skills needed for effective mobbing.

InfoQ readers can download a sample chapter from Code with the Wisdom of the Crowd.

InfoQ interviewed Pearl about the structure that mob programming uses and how people interact, selling mob programming to managers or company's executives, mob retrospectives and optimizing mobbing, remote mobbing, and re-establishing the habit of mobbing.

InfoQ: Why did you write this book?

Mark Pearl: I had seen massive benefits from mob programming with my own work and wanted to see greater awareness of the practice in the industry. Initially I wrote a series of articles about mobbing, and the book seemed a natural progression from those articles.

InfoQ: For whom is it intended?

Pearl: This is a book intended for anyone involved in team based software development. I’ve found the word team means different things for different people in our industry. In this instance I’m mean a small group of software developers who work together to accomplish a common goal.

InfoQ: What's your definition of mob programming?

Pearl: I like to define it as a software development practice where three or more people get together at a single machine to solve a problem together. Think of it as similar to pair programming, but with more people.

InfoQ: What structure does mob programming use and how do people interact?

Pearl: It helps to have some structure, especially when you are new to mobbing and still figuring out how it works. In the book I talk about an approach I’ve seen several new teams use.

First, identify as a group what problem you are actually wanting to solve together. You have to be aligned on this, else you will go all over the place and people will get frustrated really quickly.

Once there is agreement on the problem, as a group outline a general approach to the problem. I usually do this at a whiteboard (in fact, I find having a whiteboard near to the mob is as critical as having a screen to show the code). Next, we put everyone’s names into a list; we use this list to determine the order of the typists and then we start the coding part of the mobbing.

During the coding part, the person at the top of the list takes on the role of the typist, everyone else forms what I call “the rest of the mob”. We work in fixed 10-minute intervals. When 10 minutes pass, the next person on the list takes on the role of typist and the previous typist rejoins the rest of the mob.

Now, really important is that the typist not be the programmer; instead, the typist is like a  smart assistant, it’s their job to implement what the rest of the mob asks them to do into code. It’s up to the rest of the mob to work together as a group to direct the typist on what to do; I like to think of this as programming through the typist.

We keep following this pattern of swapping typists until the mobbing session ends. At the end of the session there is a quick chat about what worked, and what we want to do differently next time.

I know this may sound confusing, and it’s actually easier to understand if you see how a group mobs. I did a time lapse recording of us mobbing a while back which is worth watching to understand better. You can see it in a day and a life in a mob.

InfoQ: How can developers “sell” mob programming to their managers or to the company's executives?

Pearl: I think often as developers we make the mistake of trying to sell the technical benefits we get from mob programming to our managers and execs. I don’t believe this is a great approach; instead, I encourage developers to focus on the opportunities that mobbing offers their managers and focus on those. There are a number of benefits a manager gets from their team(s) mobbing. Some of the ones I’ve seen include:

• Fewer keyperson dependencies on core systems
• Higher retention of staff from increased upskilling & learning on the job
• Happier customers because fewer defects get to production

InfoQ: In the book you suggest to close a mobbing session with a mob retrospective. What's the purpose of it and what’s the way to do it?

Pearl: A mob retrospective is a mini retrospective done directly at the end of a mobbing session focused on how the mobbing session went. It gives those in the mob an opportunity to share what’s working for them and put forward ideas on what they would like to change in future mobbing interactions.

I’ve found these retrospectives to be really useful early on when a team is starting to mob and people are still trying to figure out how to work together. With time as things settle, the value is reduced and at some point it feels natural to stop doing them.

There are many ways to do a mobbing retrospective; in the book I suggest using a technique borrowed from Edward de Bono’s book Six Thinking Hats, where you separate thinking into clear functions. Because a mobbing session typically only goes on for a few hours, it was important for me to find an effective way to do a retrospective in a very short period of time.  I liked de Bono’s approach because it focuses on a group.

The way we do it is we start off spending two minutes focusing on the facts around the mobbing session, things that cannot be disputed. Once we have covered those we spend three minutes on positive thinking (i.e. what worked well in the session), then three minutes on critical thinking or what didn’t work well, followed by five minutes on constructive problem solving (proposed adjustments we would like to try next time), and finish off with three minutes on deciding what proposed adjustments we will actually adopt. The whole thing can be finished in under 16 minutes.

InfoQ: What can be done to establish a collaborative mindset?

Pearl: I believe it starts with a dual commitment; being committed to achieving your own personal goals as well as being committed to achieving the goals of those you are working with. In the book I describe it as moving from “me the person” to “we the group”.

Now, that can be challenging at times, especially in situations where it may appear that you have conflicting goals. In those times you have to really get good at listening to others and working through the differences to get to common ground.

If there is one thing I’ve learnt over the last few years, is that collaboration- especially where there is diversity of opinion- can be tough, but the end result is usually something way better than anything we could achieve on our own.

InfoQ: How can teams fine-tune and optimize their way of doing mob programming?

Pearl: That’s a really good question. I see a lot of teams go through the mechanics of mobbing without ever reflecting if the mechanics are suitable for the work they are doing, which leads to a poor mobbing experience for some types of work.

Fine tuning mobbing starts off with being intentional around how you are interacting with others, and regularly reflecting on what you are doing. The mob retrospective we spoke about earlier is a really good example of being intentional around that. With time and reflection you begin to recognize how to adjust your mobbing to the types of work you are working on.

In the book I cover several scenarios where you should probably adjust your mobbing. One common one I cover is how to mob when one person in the mob is the expert and everyone else is new and just learning. Often, inexperienced mobbers make the mistake of selecting the expert as the typist. This may seem like a great idea, however I find it’s actually better to keep the expert away from the keyboard and rather have them focus on helping the rest of the mob fill in the gaps in knowledge.

Other common scenarios that I cover in the book where I suggest adjusting how you mob include working on explorative work and working on trivial work. You’ll have to read the book to find out what adjustments I suggest in those situations.

InfoQ: How can we do remote mobbing?

Pearl: Personally, I haven’t had much experience with remote mobbing; I’ve always worked in environments where we have been physically co-located, however I am aware of teams that do remote mobbing and are successful at it.

In the book I included one such team’s experience with remote mobbing. Most of the pains they had were around tooling and being able to communicate effectively as a group. They experimented with several different tools and ended up with Screenhero as their tool of choice.

Putting all the technicalities of collaboration technology aside, they felt their secret to success in remote mobbing was having built up a strong relationship and understanding of how they work together as a team, prior to starting remote mobbing. This really resonated with me.

InfoQ: If teams who were doing mob programming stop doing it, what can be done to re-establish the habit of mobbing?

Pearl:  When I hear of teams that have had this happen, I like to first establish why. Sometimes it’s because mobbing wasn’t appropriate for the type of work they were doing and just wasn’t working. If that’s the case, I have no problem with them stopping mobbing; we should be using the best tools/practices for the job.

Often though, the work is well suited to mobbing and the team has just fallen out of the habit of it. A great word to describe this is “entropy”, which means a gradual decline of something into disorder.

Like many other human things, I’ve found that mob programming also suffers from entropy. The key to countering entropy is early detection—the sooner you realize you are slipping into old habits, the easier it is to recover. In the book I suggest a four step approach:

1. Identify what is contributing to the entropy.
2. Identify what you can change going forward to avoid these contributors.
3. Check in daily on your progress.
4. Remember that slipping happens.

It’s tempting to say it just happens, but in my experience there are always underlying contributors for why a team stops mobbing. It could be something as simple as struggling to get mobbing started each morning, or not having a workspace that is comfortable to mob in. Identifying what you feel has contributed to entropy is critical.

Once you’ve identified what you think are the specific contributors, you need to come up with counter measures. For instance, when struggling to get mobbing started each morning, a countermeasure may be to be intentional around gathering the mob (I suggest a few techniques on how to do this in the book).

Whatever you come up, with write it down and make it visible to the team so that as a group you see it every day. Then find a way to remind yourself of these countermeasures daily. You may decide as a team to call it out every day at your stand up meeting, or to set alarm reminders on your phones—whatever works for you is fine, just get a daily reminder.

The last thing I suggest is realizing that entropy happens and is a human thing. I've seen teams beat themselves up if they are not perfect all the time, and that isn't useful. When you realize you are falling out of a useful habit, inspect, adjust, and recommit. In my experience, with time and continued effort this happens less and less.

About the Book Author

Mark Pearl has been developing software professionally for over 15 years. He is an active participant in the Mob Programming community since 2015, and has helped teams all over the world adopt Mob Programming with exceptional results. Pearl lives in Auckland, New Zealand, where he enjoys the outdoors with his family.