Adjusting Team Processes for Regular Mobbing

The more your team mobs, the more likely it is that your team processes will need some adjusting, or at the very least, consideration for adjustment.

Mob Programming and Scrum, Kanban, Waterfall, etc.

A common concern for new mobbers is how mobbing impacts their current methodology: “My team does methodology X (put Scrum, Kanban, Waterfall or any other development methodology in its place), can I do Mob Programming and still follow this methodology?”

The short answer is “Yes.” Mob Programming doesn’t discriminate on a specific development methodology. When I asked the Mob Programming community what methodology they use, the response was varied: Scrum, Kanban, Scrumban, FAST Agile, XP, Directed Discovery, Lean, you name it. Chances are, you can keep your current development methodology in place and mob.

If there’s one thing that might prevent your team from mobbing while following a specific development methodology, it’s if your development methodology explicitly requires tasks or pieces of work to be assigned to specific individuals upfront, with the rule that nobody else is allowed to work with that person while they’re working on that task. However, I’m not aware of a development methodology that does this (although I wouldn’t be surprised if there was one out there).

While development methodologies vary from team to team, there are two team activities common enough across most teams that they’re worth examining further in the context of Mob Programming: daily stand-ups and code reviews.

Your Daily Stand-up

If your team is following an agile process, you probably have a daily stand-up where the team gets together to talk through what they did the previous day, what they plan on working on today, and how they plan on doing it. The more your team mobs together, the more in sync they’ll be; this often means fewer things to talk about at stand-up meetings. In fact, you can even consider reducing stand-ups to just two questions:

• What is the most important thing we need to get done today?
• How are we going to get it done?

Getting your team to align on these two things encourages appropriate mobbing. But keep an eye out for generic answers. If at the end of the stand-up you’re not sure who’s going to be involved in what for the day, speak up—you’re probably not alone. The primary purpose of this kind of stand-up is to figure out how you’re going to collaborate with others on the work. Once it’s clear what the most important thing is for the day, getting people to work together to get it done becomes a natural next step.

Dropping Daily Stand-Ups

Some teams that adopt Mob Programming stop doing daily stand-ups altogether because they no longer find that it adds value. While this may sound sacrilegious to some, think of it this way: if the purpose of the stand-up is to sync up on how different work is progressing, and the team already knows what’s going on because of the mob, are stand-ups still needed?

Before you drop daily stand-ups, be aware that it’s not for everyone; usually you should only consider it if your team mobs all day, every day, and everyone in the team is also in the mob; for everyone else, a daily stand-up still makes sense and adds value to your team.

Code Review Process

If your team has an existing formal code review process, what happens to your review process on code that’s been created by the mob?

Mobs handle this in various ways. The two most popular options are (a) making no changes at all, or (b) using shared mob credentials.

No Changes

The first approach is to simply not change anything, and to treat mob code the same as any other code. However, for some mobs, this may seem like an unnecessary waste—why formally review mob code if the review has been happening by the mob while the code is being written?

Shared Mob Credentials

Another option is to keep code review and use a shared mob credential for checking in mobbed code. This allows you to easily maintain your code review processes for solo code while dropping it for mobbed code.

If you go this route, and you have a security admin that maintains your version control credentials, expect some resistance when requesting a generic shared version control account. One of the pillars of security is traceability (the ability to trace something back to its original creator). At first glance, having a shared version control account seems to violate this idea. However, in this case, you still have traceability; the code is created as a group, not as an individual, and it’s owned and maintained as a group, or in other words, the team has collective code ownership. Collective code ownership was advocated by early extreme programmers. The code base is owned by the entire team and anyone may make changes anywhere. Martin Fowler^[47] explores the concept on his bliki.^[48]

The challenge for many security admins is that most version control tools are designed with a “single commit” in mind, and to deviate from this means you’re doing something wrong. If you can get them to understand this is a restriction on the tool rather than doing things the wrong way, you’ll have better luck getting it approved. Often, simply explaining the concept of collective code ownership to your security admin resolves this concern.

Team Retrospectives

Hopefully, regardless of whether your team follows an agile methodology or not, you have a regular recurring meeting where you can reflect as a team on how things have been done in the past and how to become more effective going forward—in the agile world this is often called the team retrospective.

As part of the mobbing recipe in ​Learning from the Experience​ it was suggested that you have a mob retrospective after each mobbing session. In a mob retrospective, you reflect on how the session went and what can be improved going forward. But don’t confuse the mobbing retrospective with the team retrospective—they are different things. The mobbing retrospective is focused exclusively on the activity of mobbing, while the team retrospective has a much wider focus on all things team-related.

Over time, as your team gains experience in mobbing, you may feel that the mobbing retrospective is unnecessary overhead—if you start feeling this way, drop the mobbing retrospective; it’s a useful activity in the early days but can become overkill with time.