How to get started with mobbing / ensemble programming

Music has been an important part of my life from early childhood. Some of my best memories involve live music. Playing duets with my best friend on the piano, going away on music tours, going to a live Robbie Williams show, and spending a week on the Mozambican coast scuba diving during the day and listening to live music at night. When a group of talented musicians get together magic happens. Time stands still as I observe the play between different instruments to create art.

I am not really a musician, though. I stopped playing the piano in my late teens. My art is the art of software development, which is strikingly similar to the art of making music. It takes more than mere talent to create a great team. And it takes a great team to create complex software. This short guide offers a practical way to understand and get started with collaborative work sessions in the workplace. Learn how to prepare for teal organizations and the future of work, where decentralized collaboration replaces management and control.

Extreme relationships

In my years of developing software, Extreme Programming (XP) has been one of the most impactful methods I've come across. It's what I look at for the day-to-day, practical "how to" of building software. What I love about XP is that has plenty of room for play. It suggests a few ingredients that will create autonomous, productive teams that are able to deliver high-quality software, without prescribing an exact recipe, like most other methodologies out there. Similar to a skilled chef who is able to create various dishes from the same ingredients because they understand the science of each ingredient, XP focuses on key, but foundational, practices that create high performing teams.

XP originated by answering a simple question: "What works?", and "How can we take that to the extreme?" It's firmly grounded in evidence.

XP aims to amplify the good things that help teams deliver high-quality software.

Naturally, mobbing, or ensemble programming, is an essential method to look at as it amplifies not only the real-time skills when working on a specific problem, but also the relationships within the team. And let’s face it. If you're really honest with yourself, it’s the relationships that keep you in your day job even when you dislike your boss, the salary that's just never enough, the rigid structure, or even the product you are working on.

When you have strong relationships in a team, no problem is too big or too difficult to resolve. Working overtime or putting in extra effort when the going gets tough is a naturaly by-product of the strength of the relationships. When, however, you have weak relationships, the smallest problem can cause the entire product to fall apart. No-one is willing to go the extra mile, and everyone is just doing as little as possible and cut corners whenever the opportunity arises.

In the age of AI focusing on the strength of relationships in the team is even more important than before. With AI taking over all the repetitive, boring and easy-to-solve challenge in a business, the collective intelligence of the humans in the team is freed up to innovate and solve the wicked problems more easily. Teamwork and collaboration is essential to make this happen, which is why including ensemble sessions in your work is so important at this time in history, while AI is still in its infancy.

Like a good jazz band, ensemble programming is when a bunch of software crafters come together to build really good stuff!

Each artist in a jazz band has mastered their instrument and brings a unique skill to the table that amplifies the experience ofmaking music. Similarly, each software craftsman (or woman) has mastered their skills and uses their specialty to amplify the shared knowledge of the team. Maybe one person is strong on security, while another is strong on simplity, and another might be strong on using a specific technology. And whether you're building software or supporting customers in a call center, the principles of mobbing remains the same and it can be used in any industry, not only software development.

Benefits of ensemble programming

At first glance it might seem very unproductive to have 3 or 5 people working on the same piece of software when each could work on a separate piece of a larger project. Although it sounds counter-intuitive there are, however, more benefits than disadvantages to having a group of people work on the same problem at the same time.

As ensemble work is still such a new practice, it has not been studied extensively. There are some evidence that indicates the mobbing can increase productivity, problem-solving, code quality, and general morale and motivation. A more practical resource is to watch is the Mob Mentality podcast where pioneers in the field are interviewed.

While formal research is still catching up, collaborative ways of working have already been widely tested in practice. Here are some tried and tested benefits of ensemble sessions:

• Faster delivery with fewer delays

  Ensemble programming reduces handoffs, waiting time, and rework. By solving problems together in real time, teams often achieve higher overall throughput than individuals working separately. Research on flow and lean systems shows that focusing on one piece of work at a time often leads to faster and higher-quality outcomes.

• Ensemble work breaks down knowledge silos

  Knowledge silos are a major risk for any team. When only one or two people understand a critical system, the team becomes vulnerable to turnover, illness, or unexpected absences. Ensemble programming spreads knowledge organically through shared context, reducing reliance on documentation and individual experts.

• Ensembles produce higher quality products and services

  With multiple eyes on the code, defects are caught earlier and design decisions are improved. Ensemble programming leverages collective intelligence to enhance code quality and reduce technical debt. Including AI as a team member in the team can amplify this effect even further by providing instant suggestions and catching common mistakes that humans missed.

• Ensembles allow for real-time feedback, increasing momentum

  Traditional code reviews introduce delays and context switching. Ensemble programming removes this waiting time by providing immediate feedback as the work happens.

• Ensembles include multiple perspectives in one cycle

  Diverse perspectives lead to better solutions. Ensemble programming brings together different viewpoints, experiences, and expertise to tackle problems more effectively. Combining perspectives early reduces defects and improves design quality - a principle supported by decades of systems thinking and lean development.

• Ensembles increase focus (pomodoro style)

  Ensemble programming supports one-piece flow, a lean principle clearly explained by Henrik Kniberg. Focusing on one problem at a time increases throughput and reduces cognitive load.

• Ensembles create stronger team cohesion

  Working closely together builds trust and camaraderie. Ensemble programming fosters a sense of shared ownership and collective responsibility, strengthening team cohesion over time.

• Ensemble sessions levels out skills

  Ensemble sessions are especially powerful for onboarding and skills development. Knowledge spreads through shared context instead of documentation alone. Learning happens in real time while still being productive, making learning more effective as well as requiring less time and money for upskilling as it's integrated into productive work. In the future of work, management and control is replaced by trust and autonomy, which makes ensemble programming a perfect fit.

• Ensembles improve team communication

  The driver–navigator model requires clear articulation and active listening. Over time, this dramatically improves collaboration and shared understanding within a team. It develops soft skills that are hard to learn and practice out of context in a classroom setting.

How to get started with ensemble programming

While there are many more benefits to having an ensemble session, let’s move on to how to get started. Essentially, the concept of ensemble sessions is that all ideas must go through someone else's hands. By explaining your idea to someone else it already filters out any assumptions before it becomes a tangible artifact. Below are the most important things to consider:

Assign and understand roles

To begin with it is essential that each participant understands the different roles and who is responsible for what during a session. At Cucumber’s new contributor’s ensemble, we created a manifesto to remind us why we’re there and what’s most important, together with a summary of the different roles. We use this at the start of each session and have it available for people to reference at any times.

The top part contains our most important values, while the bottom part summarizes the different ensemble roles, namely the driver, navigator, and next-up. Thinking of the analogy of a rally race, ensemble programming has a driver who is the person behind the keyboard (or wheel in a rally) and also the only one typing, while the navigator relays instructions on what to do and is the final decision-maker. Any other participants are added to a pool of next-up players who awaits their turn to take the driver or navigator role as it rotates.

If you are not the active driver or navigator, you can do research to help the driver and navigator, point out errors, or contribute in any other way that will augment and improve the experience. If there is more than one person in the next-up pool of participants, it could be useful to assign a specific perspective to them — either what they are already very skilled at, or something they want to get better at.

Make sure everyone understands each role's responsibilities and constraints. Remind them that everyone gets a chance to drive and navigate. If you don't agree with an idea, you can always suggest a change when it's your chance to be the navigator. Consider assigning more specific roles to non-active contributors to ensure they remain engaged while the driver and navigator is center stage.

Rotate roles frequently

One of the reasons why ensemble programming is so much more engaging than traditional programming is that each role is time-boxed and rotates, thus everyone gets a chance to be the driver and the navigator, while everyone also routinely gets a break.

Rotating roles keeps engagement high and distributes learning evenly. Tools like mobti.me can help manage rotations and make sure everyone gets a fair and equal chance. Change the driver and navigator every 5-7 minutes to maintain focus and energy. For more experienced teams, increase the rotation time and for more junior teams, decrease it. Most people can sit through 7 minutes of discomfort, which makes learning new skills more accessible.

We recently started changing our rotation based on tasks rather than time, thus you don’t have to use a timer. What is more important is, like lean coffee, you rotate and everyone gets an equal chance to participate. Limit the session to 90–120 minutes to start with. Less than an hour might be too short to get value out of it, while more than 2 hours requires a break.

It could be fun to add an AI role to the team that checks the code for any risks and essentially become an early risk manager.

Limit the group size

From my own experience and talking with other practitioners who have used ensemble programming in different setups, the sweet spot is to have 3–5 participants at any given time. The minimum number of participants to be considered an ensemble is three, one person for each of the primary roles. The maximum productive limit is five participants, in my opinion, although some teams include more than 5 people.

My experience has been that engagement drops when the time between driver and non-driver role become too long. Or, in other words, the ratio of time being an active participant (driver or navigator) should be at least 3 times as much as the passive participant role to keep engagement high. I recommend 3 or 4 people as the core team and invite add-on roles for specific sessions based on needs as they arise. For example, maybe you want to include a product owner, or someone strong in a specific technical skill to help you complete a goal.

When there are more than five people, it becomes difficult to keep everyone engaged and the risk of side conversations increases. If you have a larger team, consider splitting into multiple ensembles working on different problems or projects, or perhaps different solutions to the same problem.

Pick a suitable task

This is probably the hardest part to get right. Make sure the task is not too difficult or too easy. It needs to be a task that requires collaborative problem-solving. There needs to be a reason to have a team come together to work on the same task. If it is normal "grind" work that just needs to get done, it would most probably be more productive and engaging to just go do it on your own. However, it might be much more fun to take boring and repetitive grind work and do it together in some cases. It really depends on the task at hand and the personalities within the team. Ultimately you need to experiment and see what works for you.

It is recommended to start with easy, small tasks that can be completed in one session just to get used to the mechanics of ensembling. However, as you become more familiar with the mechanics, pick more complex tasks that require problem-solving, similar to how you would select complex pieces of code to go for a review rather than just everything.

As already mentioned, not all tasks are suitable for mobbing. Tasks that are too simple may lead to disengagement, while overly complex tasks can cause frustration. Look for tasks that benefit from diverse perspectives and collective intelligence. Working in an ensemble is more mentally taxing than working alone, so 2 - 3 hours per day is more than enough to get started, while a full day of mobbing is unrealistic, unless the teams itself rotate.

Use the right tools

Not all tools allow for real-time remote collaboration and that might make it more frustrating and timeconsuming to switch roles than working alone. There are a growing number of tools available to enable code sharing sessions. Look for tools that support collaboration. Tools such as VS Code Live Shareor IntelliJ IDEA reduce friction and enable real-time collaboration.

One of the biggest complaints from the earliest mobbers were that it takes too much time to sync code between rotations. Using live code share allows all the participants to contribute to the same codebase without needing to sync code manually. For non-coders the same constraint applies. You need a tool that will allow multiple people in different locations to work on the same piece of work at the same time.

You will also need a timer. As mentioned earlier, we use mobti.me but there is a growing range of options available to pick from. You can even use google timer or your phone if you don’t have any other timer. The important part is that someone keeps track of the time to ensure that everyone gets a chance to drive and navigate. The best tools are the ones you're comfortable with. Things to look out for when selecting a timer are the ability to add names, the ability to rotate, and the ability to change the time interval.

Make participation voluntary

As a professional “playoneer” (someone who understands the mechanics of play as tool for innovation, collaboration, and creativity), I strongly believe in voluntary contribution. If people choose to show up, it works. If people only show up because they have to, it doesn’t really work and you have a false sense of confidence. It might be harder to face reality if it isn’t what you want, but it’s always harder to face the consequences of living in a bubble. The key benefit of ensemble sessions is that it leverages relationships and intrinsic motivation. Forcing people to join a session may be counter-productive and even harmful.

To get maximum buy-in and participation it is essential to make these sessions voluntary. The law of two feet should always apply, which states that if you feel that you're not contributing or learning anything and can use your time more productively, use your two feet and go somewhere else.

Reflect regularly

Finally, the single most important rule of all continues improvement programs is to reflect and allow a space to critically evaluate what’s working and what not, and tailor the experience to the unique set of skills, needs, and personalities in the room. Even if you break all the other guidelines provided in this guide, having the space to reflect and learn will ensure you get the most out of the session. Agility, after all, is the ability to seamlessly respond to changing needs. The retrospective and reflective spaces are the single most important aspect to rate a team’s agility. End each ensemble session with a retrospective to identify successes and actions to improve.

Even more important than identifying actions is to act on these actions. Ensure that there’s not too many actions and that the actions get checked off before adding new ones. And that’s a beginner’s guide to getting started with ensemble programming.

Conclusion

Ensemble programming is not about speed. It is about flow, learning, and shared ownership for true productivity and to any successful teal transformation. When people solve problems together in real time, quality improves and knowledge stops getting lost.

If you need help implementing ensemble programming, book a free discovery call with me at funficient.com.