A full week of mob programming with 8 teams fully immersed

I have been advocating for mob programming for a long time ago. Before to know more about this technique, I was a super fan of pair programming, and DOJO too. So, it was easy to me identify the potencial of it.

For who is looking for to know more about mob programming, Woody Zuill and Kevin Meadows has a entire book that describes with many details what is, the purpose, the how, and another awesome tips about it. You can check the book here: https://leanpub.com/mobprogramming.

A small brief: mob programming consists in grouping a team of people with different roles, that shares the same context, to develop something together. The technique estimules a total flow, basing on a single people piloting (coding or doing something in a shared monitors) and a lot of people navigating (helping the pilot on solving the problem together).

I’’ll not convince you if this is a good technique or not, because there are a lot of materials related to:

• Mob Programming: A Whole Team Approach • Woody Zuill • GOTO 2017 — https://www.youtube.com/watch?v=SHOVVnRB4h0
• Mob Programming and the Power of Flow • Woody Zuill • GOTO 2019 — https://www.youtube.com/watch?v=28S4CVkYhWA
• Mob Programming 101 — Woody Zuill — https://www.youtube.com/watch?v=s4Eg-mnx9zg

My goals here are to share with you an immersive experience that we did recently in the teams.

What if we did a full week of mob programming?

We have a shared issue in the company, that was related to performance of our services, given the possibility of scale up aggressively, until the end of year.

Eight groups of developers, product managers, data engineers, and another different roles united on solving any kind of issues: improvement on databases, micro services, refactors and new services. All planned, executed and deployed at the same week.

At the first day, we define our agreements:

1. One screen, one pilot;
2. Each 25 minutes, 5 minutes of pause, and a new pilot assumes the keyboard (pomodoro technique);
3. Let the people finish the idea or the phrases, without interruption — maintain the space’s safety;
4. You don’t need to understand all. This is not a competition!

And we repeat this at the beginning of all days. The question “what we want to solve today?”.

During the day, we visit all the groups to guarantee the agreements and reforce the messages, but only in the first days. After that, teams were running without any kind of supervision.

Finishing the day, all the groups did a resume of the progress — “what we did today?”.

The first impressions were a mixed feelings to some people. For someones, has only one pilot it was challenging, because with two or more of them, they could see logs at the same time the pilot was coding or deploying a solution. And this is the magic behind the scenes in a mob: the unified flow.

Flow: it’s a high effective mental state of a person completely immerse in an activity

The team flow is one of the secrets of doing a mob. We stimulate the collective ambition, mutual commitment, sense of unity and group progress, and finally, a mutual confidence. If a developer don’t know how to see the logs, the navigators can help. If a product manager don’t know to deploy an application, the navigators will guide her.

In software development, when we achieve the team flow, each of story flows from the idea to the deliverable. The software works directly without queues, without backlog, or distractions, or interruption, or multitasking.

Summing up: paraphrasing Woody Zuill, “all the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer”.

Results

We did a final presentation, with all the results, at the end of Friday. One slide summarising the progress for each group. It was visible how the energy was flowing between the people, a energy of collective progress.

We saw a lot of deliveries, but the main deliverable was shipped: a new way of working together!

After that week, many teams started to use mob as a new method to solve and do the job – some teams used to define their SLOs, and discover where to measure service levels. A new group was created to study tools for remote mob programming.

Conclusion

There are some final thoughts that I want to share with you:

1. Hands-on it’s always better than theory. If we just did a talk presenting the mob programming, without providing such experience, probably the absorption could be so much lower than the immersion;
2. Maintain the agreements. Even hard, the agreements are the pilar of a good facilitation or technique.
3. Feedback, always. During the event, we collect feedback and evolute infrastructure (we got new monitors — thanks, Veronica #EasyTech), change some schedules like coffee-break time, etc.

You can test it now, even if not decided to do in a week. Experiment mob programming with your team!