Cross-functional mobbing

At Mint, we are always looking to improve our processes; we don’t believe that one size fits all, and this is particularly the case when working in an agency business. Without this flexibility it becomes difficult to deliver projects successfully, as it means you can’t adapt to client needs.

It was this that inspired us to try hacking ‘Mob Programming’ to include the whole team.

CONTEXT

To give you a brief overview of how the production team tends to work on a product-based project, we take the following steps:

1. Together with the client we decide on the ‘focus’: this can mean anything from the whole site to an individual call to action, but in general, it relates to a given ‘feature’.
2. We gather the requirements in collaboration with the client.
3. The UX and development teams discuss the needs.
4. The UX team mocks up a detailed wireframe.
5. The client receives, reviews and provides feedback. The process from 1–5 is repeated, until both parties are happy.
6. The UX team hands over to the development team.

SO WHY CHANGE?

On paper (or screen), this looks fine, but in reality, it’s not. You can see there are clear boundaries of responsibilities which inevitably cause friction. Cracks become more apparent as soon as time constraints are added into the mix. Pressure results in steps being skipped or overlooked.

With this in mind, being a developer, I set out to try and solve the problem. After a few discussions with the production team, it became apparent that improving the current process would not work for every team member — we needed everybody to be happy for this to work. Otherwise, we would just be shifting the pain elsewhere.

So we decided to look at it from a whole new angle. There is a software development approach you may/may not have heard of, called Mob Programming:

Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer. This is similar to pair programming, where two people sit at the same computer and collaborate on the same code at the same time. With Mob Programming the collaboration is extended to everyone on the team, while still using a single computer for writing the code and inputting it into the code base.

The idea seems simple but is generally only considered within the skill-set of a programmer. I got to thinking, why can we not expand this across various disciplines? It works well for development, but what is to say that we cannot achieve the same thing with the entire team?

More importantly, getting differing perspectives on the feature, and asking questions like the below, would allow us to make more informed and better decisions:

• As a developer: Is it functional? Is the codebase as clean as it could be?
• As a UX designer: Does the UX work? Does it look visually appealing? Does it feel right, for example, button Y being in position X?
• As a product owner: Does it achieve the business logic? Do we have everything we need for the feature to be a success?

WHAT DID WE DO?

As described in the quote above: Mob Programming is a software development approach where the whole team works on the same thing. We decided to tweak this to have more than just programmers; we wanted to have an entire team.

At any one time, we would have a Software Developer, Front-end Developer, UX Designer, and the Product Owner. We would then book a meeting room for the afternoon, and we would all sit down and look to solve the given problem collaboratively.

We laid out the following guidelines for the process:

• Mobs are run as and when we feel we need them. i.e. for a new feature or a large functionality change.
• Mobs would only be a half-day sprint.
• In the name of future-proofing the concept we ran our mobs between 2–6pm GMT. We have an office in NYC, so we needed to accommodate for a time when a member of the team from New York could be involved.
• Mobs will be started with a 10-minute chat. Within this 10 minutes, we are going to look to create seven tasks to knock out by the end of the mob.
• Mobs will be ended with a 10-minute wrap-up chat + documentation.
• There is only a single computer open at any one time, excluding remote workers and product managers, although we will try and enforce this as best we can.
• We assign a ‘Driver’ who works on the one open computer for 25 minutes. After which we will take a 5-minute break before moving on to the next 25 minutes where somebody else becomes the driver.
• After every two hours, we will take a 10-minute break so individuals can do other things i.e. make a phone call, check emails, check Twitter, etc
• On any one Mob we have a ‘Time Captain’ who is in charge of keeping an eye on whether we are spending too much time on X and should move on. The ‘Time Captain’ is ultimately in charge of time boxing discussions and disagreements.

After our initial approach to this, it was clear that some of these rules needed to be changed to be more inline with the nature of our team.

1. One computer does not work in a cross functional team. Having one computer works well when all the people work in the same discipline, but this is what we wanted to get away from. We swiftly decided that working on one ‘focus’ would be more applicable i.e. someone suggests we are focusing on X for the next half hour, and we all help each other out on achieving that focus.
2. We felt that seven tasks was slightly ambitious given the timeframe. We decided to cut this down to six. The extra time meant that we could slip past 25 minutes without worrying that we would not finish all the points.
3. The work we did in these sprints was not 100% — it was rough around the edges, to say the least. So we decided to aim to reduce the number of things we wanted to achieve i.e. use two of our now six tasks to do X instead of one. Or we use the other half of the day to polish off the work.

Was it effective? Did we achieve what we wanted to achieve?

Was if effective?

Yes, but it was not a silver bullet. It allowed us to prototype/build features in a quick and efficient manner. We were all able to have and voice our opinions on how X should be done. Having our voices heard allowed for a more collaborative approach to feature building. We found it also reduces the roadblocks that you may come across when moving pieces of work from discipline to discipline. However, at times there were situations where some members of the mob could not be influential in a given 25-minute sprint.

Did we achieve what we wanted to achieve?

Ultimately the goal for us was to reduce the friction between disciplines and expand domain knowledge, and we more than achieved this.

We were all making informed decisions, and we had clarity on where the ship was going. Before this, as a team, I believe we profoundly underestimated the benefits of all working on the same thing at the same time in the same room.

Conclusion

To conclude, Cross-functional mobbing is great. However, it only really works well if you can answer yes to any or many of the below:

1. Is the feature clear and well defined? — Is it clear what needs to happen? If there are any big elephants in the room, these need to be addressed prior to mobbing.

2. Can all members of the team be involved? — It doesn’t make sense to have a UX Designer and the Product Owner involved if there need to be a lot of data model changes before any work can be undertaken.

3. Is the team having difficulty with comprehension? — Cross-functional mobbing is great if the feature is difficult to comprehend. Or if the changes you make will have a substantial effect on current or up-and-coming features.

4. Is the production team always becoming blocked? — At times it is easy to get bogged down by the tiny details of features. Cross-functional mobbing allows you to look at it from a higher level and from different angles than say you would if you did not have the Product Owner in the room.

5. Does the production team need clarity? — Making sure that everybody understands the problem and how the pieces of the puzzle come together is hard at times. Cross-functional mobbing solves this issue.

6. Does the product owner have full autonomy? — The Product Owner needs to have total freedom in this scenario. If they need to go back to their boss to clarify individual decisions, this approach doesn’t work. The aim is to make quick, iterative and informed decisions.

I would implore anyone involved in product development to go and try this approach. It is informative and allows you become empathetic towards different disciplines. By becoming empathetic towards various disciplines, it will reduce tension and in turn breed productivity in the product development cycle.

I would like to give special thanks to Monika for her talk on “Designing in Cross-functional teams” about Mob Programming at Front End London — prompting my research into this.

Originally published at mintdigital.com.