Having multiple developers working on the same problem at the same time is a tough sell to a manager or director who’s only ever worked or seen work done asynchronously. Aside from convincing leadership of the value, you also need to consider how you’ll gain traction among the developers you work with.

Working together can feel extremely intimidating for most people. A friend described the issue to me when we were talking about how to get ensembles started at his work:

Individual devs might actually be the toughest sell. Most people are pretty introverted and pretty anxious about people watching them type at all.

He’s right. Not only can an ensemble be intimidating the first time you encounter it, the time savings aren’t always immediately obvious, so it can easily be misinterpreted as incredibly costly too.

It’s easiest to start ensemble working if your organization sees it as a supportive environment for rapid problem solving.

In order to help my friend, and others who might be uncertain of where to start, I’ve compiled a list of things that I’ve done, along with tips and ideas from ensemble-ing experts. These items and ideas have worked in at least one context, so they may work for you in yours, but ymmv. Feel free to adapt and adjust them to your needs.

Before you start.

Go to a few ensembles, and ensure you understand the basic mechanics of the different roles and rotation times. Take time to read a book or watch some episodes of a podcast about how and why ensemble working is effective. Understanding different patterns that you can apply in order to overcome obstacles will make your ensembles more effective. You are going to need to explain the process to your team, so you want a solid basis on how and why mobs work the way they do.

Socialize the idea of ensemble working.

Look for opportunities to raise awareness about the concept of an ensemble, and how it might benefit your team. Have discussions where you happily listen to other people’s opinions on the topic, even if they disagree. If developers and managers have previously been exposed to the idea, and they know you are not dogmatic about it, they’ll more likely be curious, and interested in learning more.

How to do this:

  • Share your favourite mobbing articles in your office slack channel (here’s one of mine!)
  • Watch for problems that mobbing could help solve and mention that mobbing might be helpful.
  • Start a book club reading a book that happens to talk about the benefits of collaborative coding. (Team Topologies and The Pragmatic Programmer both discuss the benefits of ensemble working.)
  • Share meetup events that give their members an opportunity to try out working as an ensemble (like mine!) and invite coworkers to go with you
  • Keep talking about ensembles without actually forming one, until you think you have enough people interested in trying one out.

Baby Mobs.

Start facilitating small, low-stakes ensembles. This isn’t always easy to do at work, but if you can, it’s incredibly valuable for socializing mobs further. In order to do this, you need to find something your leadership will find valuable, that is also simple enough that it creates a safe environment for anyone who joins. As these will likely be the first ensembles you’re facilitating, it’s a good idea to keep them small, and only involve people who self-select into the process. I found it took me about 10-15 of these sessions before I was actually comfortable running mobs on production tasks.

Tasks I’ve picked:

  • Simple refactoring of a piece of code (leadership was on board as this was a KT activity about an area with a deep knowledge silo)
  • Doing a kata (This was picked by the team as they wanted to learn how TDD worked. Management was on board because this let me teach 4-5 developers the skill at once)
  • Running a mob in other areas of the company, or with other departments as a networking event.

Preparation for the real thing.

Once the idea of ensemble work is well-socialized at your company, and you have a few people who might be willing to try it on real code, it’s time to figure out details to make sure that your first experiment is a success. If you’re remote, you’ll need to figure out details about how you’ll share the code to enable quick rotations. Emily Bache’s Samman book has some excellent suggestions on remote setups. If you’re co-located, you’ll need to find a space in a conference room with a large enough screen that everyone can see what’s happening at the same time. You should also consider any setup you may need to collect metrics and prove effectiveness.

Do the real thing.

This is the tricky bit. You need to find an opportunity where developers are willing to work with you, and leadership will see the value of using this new way of working on real code. For this reason, I would probably repeat the steps above until a team invites me to help them by facilitating a mob or look for opportunities where an ensemble will really shine. Situations like onboarding large groups of developers, exploring a new problem space, or working with a group of new programmers are all tasks that highlight the benefits of working this way.

Proof.

Not only is it important for your ensembles to be effective, you need to be able to prove their effectiveness in a way leadership and developers will understand. Proof can take many forms, and the best format will depend on who you’re trying to convince. Here are some options you might want to try:

  • Testimonials - If your mob had a good time, ask them to share their experience. This can be really powerful, as you aren’t the only voice pushing for mobbing anymore
  • Daily log book - Keep a journal of the 3-5 most significant things that happened in the mob that day, including things that blocked the mob. Share them with whoever asks.
  • The Puckett Experiment - Divide sprint work into two categories, one set to be done as an ensemble, and another to be done asynchronously. Work on the ensemble work 2 hours a day for a month. Measure the cycle time (time from start to delivery) and velocity (number of story points done in a sprint) of each type of work. Compare the two values at the end of a month.

That’s all I’ve discovered so far. I may add to or adjust this article as I learn more. Please let me know what you find helpful and what works for you.