Mob Programming: The Next Level Of Pair Programming

Francesca Cuda at UXDX Europe. Video: https://youtu.be/cnDRCkkChWU

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

A story about an experiment

[00:00:06] Thank you very much, thank you for the introduction. I'm here today to talk about a story, a story of an experiment of a group of people in a project trying to push the boundaries of our ways of collaborating and trying to find a new way to make teamwork more effective. And it's also a story about some reflection, my reflection after the experiment, about how mob programming may solve some of the challenges a software engineering team can have when working on a project. For example, are we building the right things? Are we building the things at the right time? And are we using the right level of quality?

[00:00:53] But before I go deeper, let me introduce myself. I'm Francesca. This is when I was about three years old, and I've been coding for as long as I can remember. When I don't code, I bake, so if you're interested in my baked creations, or if you want to hear more about what I think about technology, you can find me on Twitter.

[00:01:17] And as I've been introduced, I'm tech director at ustwo. For people that don't know, ustwo is a digital product studio. We are about 300 people all over the world, and we have one mission, that is to invent, build and launch products, services and companies that have a meaningful impact on the world. And of course impact means different things to different people, so we adapt our meaning depending on who we work with.

[00:01:44] We are a little bit different from a normal agency or digital agency. Our core business is to work with clients, and this is what we do day in, day out. But also we have our own products. Maybe some of you know Monument Valley one and two, we built that. Or Moodnotes, or Sway, that are more in the health space. And also we invite in people that want to build a company, and we do that in different ways, either by funding these people or housing them in our space in what we call the adventure floor.

One team, and deep collaboration

[00:02:21] But as I said, the core of our business is working with clients. We have a wide range of people we work with, and each one of them has, as I said at the beginning, their own interpretation of meaningful impact and their own interpretation of a way to impact user experience. But what I found very interesting is that all these companies, when we work with them, they have two important aspects very much in common. One is the meaningful impact, and the other one is working with us in the approach of one team.

[00:03:00] So our team is cross-discipline: developer, designer, product and QA, and they work together. And it's very common for us that developers and QA take part in sketching sessions with designers, so paper and pen, and try to draw what the next feature should look like. We really believe that each one in the team will bring their own experience, their own interest to the table when designing a product. So that for us is very important.

[00:03:31] But one team also means for us being embedded so much into the client that it's very difficult to distinguish which is the client and which is a person from ustwo. And this is because we really believe in deep collaboration, and deep collaboration comes from, also I believe, the collective. The collective is the way where you can embrace the real genius and where real genius actually happens. And one of our goals is to actually explore that idea by challenging our way of thinking, trying to always find different ways to collaborate, challenging our daily ways of working. So, what if it's not pairing? What else can it be? And also, as I said, we like to include all the different life experiences while we work on a product. This is the context of the environment in which the idea of mob programming came from, and where the experiment started.

What mob programming is

[00:04:44] Let me give you a little bit of information about mob programming for people that have never heard of it. It is when the whole team works on the same thing at the same time in the same space and at the same computer. So for some of you it might be quite frightening, but it's actually a very intense and rewarding experience.

[00:05:05] It is about focusing the whole team on the single most important thing and problem, and it is about leveraging distributed knowledge when solving a problem. And the concept of distributed knowledge comes from the knowledge that each person in the team possesses and that can help them solve the problem. It's quite similar to pair programming in the way of sitting in front of a computer and working together, but instead of being a one-to-one type of interaction, it is the person on the keyboard and the rest of the team. So there can be quite some similarities and some differences that I will touch on later on.

The project: two weeks and one more simulation

[00:05:47] So what is our story? We were working with a client and they were an education startup. Their goal, or their meaningful impact, was democratizing education, and in particular science, especially in countries where building a science lab can be very expensive. So they wanted to reproduce the same environment of a science lab in a digital world, or in a web simulation.

[00:06:19] We were at the point in the project where we had developed different types of simulation: chemistry labs, physics labs and so on. And we had two weeks before the actual end of the engagement with the client. So we sat there and said, okay, we can spend that refining or adding more features, or we can actually push the boundaries and say, why don't we add another simulation? And when we said that to our client, he said, can you build a simulation in two weeks? And we said, well, we have some ideas.

[00:06:57] So we got there as a team. I wanted to put that on the screen because these were the main drivers of the mobbing exercise. They helped me to make this happen, so I wanted also to thank them publicly. We sat down and we said, okay, there is a type of simulation we can build in these two weeks, and it's something that, from a UX point of view, so user interaction, is very similar to something we have already built, but it has some different concept mechanics and also some different design assets that need to be included. And we said, okay, that's an interesting challenge.

[00:07:41] The client was on board with that, and also we said, the team already pair with each other, they know the concept, maybe they will be also interested in seeing how that is going to work. And also we realized the people in the team were already thinking about how they can share more amongst developers, because of course when you work in different streams of features, or different simulations in our case, one developer was taking ownership of a single stream of work. So there was the need, or it was already the intention, to share more knowledge.

The survey before we started

[00:08:25] So our delivery coach Maria, that's her real name by the way, she said, okay, let me send a questionnaire before we start the experiment and see what people think, what people know about mob programming, are they worried about it, are they excited about it? This is what came out of the survey before we even started doing mob programming.

[00:08:46] People were quite enthusiastic about the idea of multiple brains working together. They found it a way to solve a problem quickly, and also to solve a blocker quickly, because in theory you should have all the relevant people in the room. There would be lots of context sharing. Especially the development team were concerned about speedy development, and it would be an opportunity to focus on one single task rather than having multiple things happening at the same time. And also there was this idea of gaining a better appreciation of other disciplines and actually understanding the other disciplines in order to be better.

[00:09:36] As for every advantage, there were some concerns, especially about how does it work when you have eight people, in our case, in one room trying to solve one problem? What will be the logistics about that? How can we manage to get stuff done? How do you keep people engaged for maybe a longer period of time? And especially from the development side, how can you go deeper into some technical discussion without feeling that you are leaving out some other people that might not have the same context of knowledge? And from the design side, how can they be integrated into the project, how is this going to work?

The golden rule and the five principles

[00:10:21] We started actually with just the top one. There was our golden rule, and then we figured out our principles as we were going along. So at the beginning we didn't have the five principles at all. We just started with the golden rule of treat each other with respect, consideration and kindness, because we knew that everyone was going into this environment, into this experiment, a little bit excited and then afraid at the same time. So we had to be respectful and mindful of that.

[00:11:00] The first principle we came up with is create our own working agreement. We didn't want to find ourselves following a set of rules and adapting to something that was a little bit clashing with our ways of naturally working. We wanted to find something that was in line with our core values as a company.

[00:11:21] Number two, it was important to keep the team focused in that period of time, however long that might be, and to find a way to not diverge to other topics. The way we achieved that is actually having a parking lot board, where everything that was coming up from discussions they were having during the session could be put on a post-it and put in the parking lot.

[00:11:53] Three, take turns on the keyboard. It is very important, because otherwise you have the effect of watching someone type, that for some might be exciting, for other people might not, and it's also quite an intense activity. So it's good to again be mindful of that and change the person on the keyboard. Be present, and these things I will touch on a little bit later on. And what was important for us is also finding opportunities to reflect on the session, on the mob programming session we had, and find a way to distill some of the principles for the next session.

[00:12:34] And number five I will say communicate, communicate, communicate, because it's very hard, when you have eight people like in our experiment, to actually make sure you are all on the same page and you keep everyone in the loop of what you're thinking, what your approach is, and what your idea of solving a problem is. So this is some pictures of some of our sessions.

What happened: the results

[00:13:01] And we actually did it. So, result number one: we managed to develop the simulation. And what was very astonishing for me is that we were able to have small mob programming sessions of about 15 minutes, followed by 5-10 minutes of mini retro, and then carry on for a length of up to two hours. So that was quite a big chunk of time, but in that time we managed, especially when we reached a kind of plateau of the learning of how to do that, we were able to develop a user story end to end in that 15 minutes. So that was very, very powerful.

[00:13:47] As a good delivery coach, Maria again sent the questionnaire straight after and said, okay, how did the experiment go? Of course we got some very, very quick turnaround because we were getting immediate feedback from others. It was very positive not to have a fixed set of rules that someone in a book put there. It's good that we were able to create the rules as we found them through the retro. It was good to make a decision together as part of a really cohesive unit. And also we managed to have actually better working relationships, because having two hours with eight people day in and day out was quite empowering.

[00:14:38] Of course there are some downs, or some things that we didn't manage to solve in that experiment, and it would be very interesting to hear if you have tried and if you have any ideas about that. The thing we really didn't realize at the beginning was that the respect and the kindness really is a really big part of the mob programming session. It takes a lot of mindfulness to always remember to be patient, to talk, to describe what you're thinking, what your ideas are. Sometimes we took shortcuts, and that means that at the end there was some work normally done in the afternoon to pick up some of the things where we had said, okay, let's do that for now and then we will release it later.

[00:15:31] We didn't find a way to introduce some software engineering practices into the process. For example, how does it work with PRs? Are our PRs still needed? Is there any meaning in having them? So, something we haven't solved. And also, in this experiment, as I said, the user interaction was very similar to something we had already done, so the design input was very limited to just providing the assets or some visual representation of how the simulation should look like. So it will be interesting to see, if you have a completely blank canvas and you need to build the product from scratch, how that is going to work, if it's going to work.

Reflections: communication and empathy

[00:16:17] So, my reflections. First of all, I really underestimated the power of communication. It's evident when you do pair programming that you should always, always talk with the other person in the pair and describe what you are doing. But in mob programming this kind of exponentially grows, because there are another seven people with you in the team, and you need to kind of trust each other and make sure you are also comfortable without knowing everything. You need to give the five minutes of, let me just try these things and then I will explain what I wanted to do. And that of course takes a lot of patience from the listener side to say, okay, I will let the person type the things down and then he or she is going to explain that back to me.

[00:17:14] And also, I thought mobbing was about coding, and instead it's actually about people, and it starts with a lot of empathy. Of course empathy can have different meanings. In terms of mob programming, empathy has three attributes in my mind. First of all, have open eyes and an open mind about what other people's solutions can be. And this means try to see the world as other people in the mob can see it.

[00:17:48] Don't be judgmental. It's very easy to say, oh, the solution is wrong. Try to avoid that, because again there is a person behind the thought that might be kind of emotionally connected to that idea. Try to find an objective way, a way to judge between ideas. And third, making sure you allow time to go into the mobbing session with the best of yourself. Mobbing, even more than pairing, is a way to amplify your emotion. So if you go there and you had a bad day, it's going to be reflected and influence the rest of the team. And when you go there and you bring the best of yourself, there is of course an amplifier effect.

Mobbing versus pairing

[00:18:40] Mobbing and pairing are very similar, but at the same time I found them very, very different. Both come with the idea of the person on the keyboard and the other one. Both come with the idea of being more effective when you combine brains to solve a problem. However, in my mind they are also very different. So first of all, you don't need to have done pairing to do mobbing. You can try mobbing straight away, there is no kind of prerequisite.

[00:19:13] And second, in mobbing, in contrast with pairing, when a person leaves the mob, the mobbing session can continue if the team want to continue, whereas in pairing, if a person leaves, it's just the end of the pairing session. And what we found is that it was very important, and again the mindfulness, that when the person comes back into the mob, you need to allow yourself and the rest of the team to actually bring the person back to the context and make sure they have not missed anything, or they are at the same level of knowledge as the rest of the mob.

[00:19:55] And also the other thing about pairing: lots of people don't like pairing. I met lots of people that say, that doesn't work for me, it isn't my style, I don't like to talk with another person, I have all of my ideas in my brain and that works fine. But make sure that doesn't reflect on mobbing. Mobbing is very different. The interaction with people is different, the intensity I found being very different, and also the way you structure the tasks and the things to work on is different. So I will say, from my own experience, give it a try.

How would a manager measure success?

[00:20:32] And if you are a manager in the room and you are listening to these things and saying, shall I try mob programming or not? The first thing that came into my mind, when the team came to me, was, how do I measure success? And of course it cannot be measured by, oh yes, I will be able to reach double the speed of the team, or the velocity of the team will increase by X percentage. That doesn't work, because of course the team needs to go through some learning, and then at that point, when they reach enough knowledge, the velocity will pick up.

[00:21:10] So my recommendation, my suggestion for a measure of success would be: is my team able to share knowledge? Do I have less time spent on merge conflicts? Do I have fewer bugs in production? So this should be your first metrics, and then move into more traditional velocity measurements.

[00:21:36] And the other thing is a question that comes very often, not only about mobbing but in general about pairing or doing a team exercise to solve a problem, and it is the infamous question: why do three or more people need to do the job of one? And this is because, I believe, when you work as a team to solve a problem, it is not about optimizing the single element in a chain and trying to achieve optimizing at the level of the individual. It is more about, how can I make the feature, or how can I develop the story in the fastest way possible? So it's about flow, flow efficiency.

[00:22:24] And last thoughts. This was an experiment, and of course I don't think it was the perfect experiment, but it was a way to push our boundaries and to try to find the innovative way that we can solve a problem. And of course I bring the expertise with me and with the rest of the team and try to improve that. But it was also a way to understand if there was a different way, an alternative way, a better way to do collaboration and to manage to have all the people solve a problem together. And with that, I thank you very much for listening.