Experimenting with Mob-Programming

Mob-Programming is a programming technique which involves all team members in collective coding sessions. After experimenting with four teams working in different contexts and application domains, we have reached several key takeaways and results. While the overall effort spent in coding is similar to that of solo-programming, the duration of coding a single feature end-to-end was reduced tremendously and the amount of learning and knowledge sharing were huge.

1.     INTRODUCTION

Mob-programming is a revolutionary technique for developing software. It’s like pair programming with 6-7 team members instead of 2[1]. At first, it seemed costly and ridiculous. However, the fact that it was spreading like wildfire in the community made me think of doing several experiments to practice the idea and test its validity.

I started with a team trying to find its way with a legacy application doing online flight booking. The team was new to the industry, and this added tons of issues and an extra dimension of complexity to the already cluttered and hard-to-understand code. Although it was not the perfect project to experiment with, we have done two mob sessions, and it was fun!

The experience was very positive, although the team didn’t continue doing mob-programming. There were overwhelming pressure and the team lacked support from senior management. However, in several hours, they learned a lot. They resolved some very difficult bugs with simple notices from team members. They felt it was very dynamic and engaging. For me, I felt this technique is key in resolving many problematic issues in software teams, and I decided to run several other more structured experiments with more teams.

This was the real story. In these experiments, I was keen to design the setup in a way which makes the overall experiment real. I selected user stories from the teams’ backlog which has similar counterpart user stories developed the old way. I collected actual effort from teams’ logs and compared it to the total effort spent in the experiment. We have spent much time trying to polish data and making sure results are valid.

1.1       Experience report structure

First, the background section describes the setup of the experiments and information about the teams which participated in the mob sessions. Then, the results section lists some of the performance measurements measured during and after the experiments. Finally, the observations and recommendations sections list some of qualitative results of these experiments.

2.     Background

Following is a summary information for teams who have participated in this experiment:

2.1       Setup of the mob session

For the session to be effective, we have prepared the setup with two simple pre-requisites:

• One big screen or overhead projector which is visible for all participants.
• A task board visible and accessible for all participants with three basic columns, to-do, in-progress, and done.

Probably, this setup has a positive effect in itself. The fact that the team has a backlog of tasks and is focusing on only one task at a time, this practice is a proven booster of team productivity. Also, me being available as a facilitator observing from the outside was also a plus. It gave me the opportunity to step in when I see the team is drifting to a side task. In most cases, all what I needed to do is to remind the team to stay focused and add the emergent task to the backlog. In other cases, the team decided to start right away on this emergent task, then resume working on the old one.

2.2       Rules of the game

Several basic rules are put into action:

1. We’ll break every now and then, probably once every 1:30-2 hours
2. It’s ok that you leave the room for any side task, not for so long though
3. Any emerging unplanned task will be put on the backlog. Usually we start with several tasks and end up with twenty to thirty of them!
4. Work is time-boxed from 10 am till 4 pm. No other “significant” work should take place outside these working hours

Again, such ground rules are extremely helpful for group activities. Having these rules, and adding on them later on, introduced a sense of discipline necessary in such dynamic exercises.

3.     Observations

It’s very interesting seeing how people interact and collaborate during the session. Here are some observations I noted:

• Contrary to what I expected, technical leaders and development managers where happier with this technique. They felt more relaxed and more productive. Plus, they appreciated learning from other team members while mobbing!
• Learning took place in all directions: Seniors taught juniors and vice versa. Old team members taught new ones and vice versa. This was amazing! One can never think of what new ideas, techniques, even inspirations he/she will learn from other team members unless he/she starts working with them hand-in-hand
• Interaction and collaboration were high, definitely higher than solo-programming, but probably lower than pair-programming. Again, this is contrary to my expectation. I expected that at least half of the team will take a long nap during the session 🙂
• Focusing on one thing and nothing else, is a skill that teams lacked at first. However, working with a visual Kanban board made the whole team sponsor the idea and move any emerging tasks to the backlog. Usually, we start with 3-4 tasks, and by the end of the second day, around 20 more issues, bugs, or refactoring tasks emerge

Apart from my observations, I collected team members observations and notes. I have asked about general feedback and more specifically about when one think this technique could be useful. Here is the feedback I got:

• It was fun! and joyful
• Some tasks would have never been carried-out without mob-programming them
• We used to do the same task again and again so many times. This way, we all do it one time!
• Collaboration with the product owner is much better; we all ask him the same question, get the same answer, no confusion, no misunderstandings
• It’s a better approach to reach the best solution for a problem
• It’s less suitable for small and easy tasks
• It may be impossible to work this way if we’re working under pressure

For the last point, this team didn’t sustain mobbing because of the very high pressure from senior management. From a traditional standpoint, senior management wasn’t ready to sponsor such a weird technique especially if they are under high pressure of delivering.

To describe the energy that I felt with the teams, I found them very thirsty for such highly instructive experience. I’ve seen them smiling and even laughing out of joy for solving a difficult bug or learning something new. Seniors felt very relieved because they do not have to explain things again and again to junior team members. Juniors started quiet and silent, then felt more confident in time when they started participating and putting their touches to the code.

4.     Impact on Effort and Duration

Now, the most interesting part in this experiment was to compare effort and duration of developed features. This is very similar to the effort spent in early 2000’s when people started questioning the validity of pair-programming. Frankly, I did this experiment to prove for myself and my fellow managers whether or not this practice wasted team effort.  Now, after showing below the results, I can very confidently advise all teams that in some situations, it will be much more economic to use mob-programming!

4.1       Preliminary setup

In two experiments, measuring effort and duration was the main concern for me. So, I have measured the actual effort the team invested in one feature as well as the duration it took them to develop the feature. Then, I compared these numbers to the actual effort and duration they spend developing one similar feature the old way.

During the mob session, I kept an eye on which feature or user story we are working on. Switching to other user stories or refactoring ideas was strictly not allowed. On one hand, this allowed the team to focus on getting things done. On the other hand, we were sure that the time spent is dedicated to this user story and nothing else.

This was very effective, because it gave me some good numbers to compare with previous numbers for similar user stories or tasks developed.

4.2       Data collection method

Numbers of actual effort spent were collected from the issue tracking time logs. In both experiments (digipro and ebrufai), the tool used was Jira. It took the teams a while to review and polish the numbers to make sure that they reflect effort spent on developing the specific features or task at hand and nothing else.

4.3       Comparing effort

As it appears in the results, there is not much difference in effort between solo-programming and mob programming. That is, if a feature takes 1 hour from 5 team members, it may take around 4-5 hours from a single team member.

4.4       Comparing duration

This is the big improvement. Duration of developing new features or doing complex refactorings end-to-end dropped by 70-90%. This wasted duration is attributed mainly to delays and task switching. This is only evident in tasks which needed collaboration between multiple team members. Therefore, new features and big refactoring tasks witnessed this big difference.

4.5       Knowledge sharing

In all experiments, team members reported that they learned a lot and experienced so much knowledge sharing. This knowledge sharing took many forms, like:

• Team members learned new coding techniques and development guidelines
• Team members learned about the business. Many misconceptions are pinpointed before they are coded and delivered to testing
• Developers learned new ways of coding from a new team member who has just joined the team
• Seniors learned about some bad coding practices from junior developers!

For me, even if mob-programming was more expensive, the fact that it boosts knowledge sharing makes it a much better choice for teams facing common challenges or starting something new. On the long term, you’ll feel the gain.

4.6       Which types of tasks to use this technique

Regarding this question, teams mentioned these different types of tasks:

1. Investigation tasks which requires group thinking
2. Development tasks which requires different sub-specialties from more than one team member to work on
3. When doing a new type of task at least for the first couple of times

In one of the experiments, we noticed the energy in the room decreased dramatically when the type of task is simple and recurring. The team felt this type of task could be done by anyone later on and we as a team should make better use of being together and work on more critical tasks.

5.     What We Learned

The key takeaway is that teams need to invest some time coding with each other. The benefits of such activity are huge. In general, team members need to collaborate and spend time and effort to talk and mingle in mentoring activities among all team members and with all of them sometimes mentors and sometimes mentees. This is perfectly achieved by mob-programming, and results in better overall code quality, better understanding of the overall structure of the code and the design decisions, much better communication and collaboration between team members, and huge leaps towards becoming a high-performing team.

In all teams I worked with they felt the need for this practice, at least for some time and especially in two cases: If they are new to each other, and if they are developing a new product or starting a new release. After a while, they may revert to pair or solo programming and plan mob-programming sessions when needed.

6.     What’s next

If you’re enthusiastic and want to try, I advise you to start with an experiment with one of your teams. Here are several guidelines and ground rules which are very useful to make this experiment succeed:

1. Select several challenging tasks
2. Book a spacious room for 2-3 hours
3. Make sure the setup described in sections 2.1 and 2.2 are taken care of by a team facilitator
4. Run the session and make sure to give a break once every 90 minutes maximum
5. At the end of the session, take feedback from the team members
6. Sometimes, this may be enough as an experiment. In other cases, you may need to find a similar task from team history and compare the effort spent and duration in both cases

There are so many opportunities to apply this idea in organizations. You may use it in developing other types of work products, like GUI design, user guide, business cases, etc. You may also apply the same collaborative team setup to boost creativity and brainstorm more innovative product designs.

It’s all about collaboration and crunching ideas together. I see huge applicability in UX design and prototype creation. I envision several designers working together on a concept, and exchanging seats while drawing concept designs.

7.     Acknowledgements

Many Thanks for all team members who were courageous enough to practice such a weird technique: pair-programming with 6 members! Special thanks to Hossam Baioumy from DigiPro and Mahmoud Atef from Ebrufai who have spent time and effort collecting and polishing data from their team logs.

Also, special thanks to Michael Keeling, the software architect, agile practitioner, and the author of Design It! From Programmer to Software Architect, for shepherding this experience report. I would say that without the help, support, and invaluable feedback by Michael, this report would not have come to light!

[1] To get a deeper dive, watch this lecture by Woody Zuill, the father of the idea