How to get started with mobbing (or ensemble programming)
I’m interested in what makes a good team great. How do you get a bunch of strangers, possibly in different geographical locations, working together productively? How do you bring out the best in a team?
These are the questions that keep me up at night.
XP has been a big part of my journey and is what I look at for the day-to-day how to. What I love about XP is that it is rather like the pot of gold at the end of the rainbow. It suggests a few ingredients that will create autonomous, productive teams that are able to deliver high-quality software, without prescribing an exact recipe. It focuses on practices that create high performing teams much like a chef will look at different ingredients and create various dishes from the same ingredients.
XP originated by answering a simple question — what works, and how can we take that to the extreme?
XP aims to amplify the good in teams that help them 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. And let’s face it. It’s the relationships that keep you in your day job even when you dislike your boss or the 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. When, however, you have weak relationships, the smallest problem can cause the entire product to fall apart.
Like a good jazz band, ensemble programming is when a bunch of artists come together to build stuff. Good stuff.
Each artist brings a unique skill to the table and adds it to amplify the experience of building software. Of course, you can use the same technique in any industry, not only software development.
Benefits of ensemble work
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. Although it sounds counter-intuitive there are, however, more benefits than disadvantages of having a group of people work on the same problem at the same time.
There has been some research on the relative productivity that supports this, but as it is still a very new practice, it has not been studied extensively. Watch the Mob Mentality podcast for interviews with some of the pioneers in the field.
But it doesn’t take any scientific research to grasp some of the benefits of working together as listed below:
1. Real-time feedback
Probably the biggest benefit from ensemble programming is that you get real-time feedback on your work, thus drastically reducing and even eliminating the biggest waste in most teams, namely waiting time.
One of the practices that have proven beneficial to increasing the quality of the software is code reviews. The problem with code reviews, however, is that often you spend a lot of time waiting for the reviewer to give feedback and both waste time in context switching which reduces productivity.
So how do you take the benefit of a peer looking at your code to the extreme? You have an ensemble session. Of course.
With ensemble programming, waiting time is eliminated, unless you uncover a problem that requires someone that is not in the session. Usually, however, all the people are there and you get real-time feedback from multiple perspectives on your code as you write it.
2. Multiple perspectives
This leads me to the next big benefit, namely adding multiple perspectives to any given problem.
I strongly believe that each person has a unique skill and that no two people have the same superpower. There is no one programmer better than another. They merely have a different skill set, or pattern recognition ability, than the next. While one might be good at one aspect of coding, like security, another might be good at algorithms, while another might be good at testing and thinking about edge cases. Putting these perspectives together greatly increases the overall quality of the product early on.
Adding perspectives reduces errors and requirements identified after the code has been released, which exponentially reduces the cost of correcting the error or addressing the requirement.
You can’t test quality into a product. You have to build it in from the start. When you include multiple perspectives early on, it increases the completeness of your design.
3. Increased focus
In lean manufacturing there’s a principle called one-piece flow, which Henrik Kniberg translated nicely to be understood for all industries here using the analogy of drawing smiley’s:
The principle essentially means that if you focus on completing one thing at a time (also called the Definition of Done in Scrum), you increase flow, or your ability to produce more items in less time. Again counter-intuitive as most people believe that it is more productive to start multiple projects and show progress on each. Scientifically tested, however, this is merely an incorrect perception and it is never faster to run concurrent projects than focus on one piece at a time.
When you are part of an ensemble you are naturally more focused and motivated. The rotating of roles ensures that you always keep your attention on what’s going on without burning out as there are rest times between rounds.
A side benefit is that it will decrease the work-in-progress, which is usually an indication of busywork rather than productive work. It will also naturally force you to prioritize work better.
4, Level out skills
Ensemble programming is also a useful tool to use during onboarding, as it levels out skills, similar to the lean principle of leveling out the workload.
In an increasingly remote first work environment, onboarding becomes even more important than it was with a co-located team. Suddenly the new person has no one to ask unless explicitly introduced to someone as they don’t overhear water-cooler conversations that might prompt someone to realize who is good at what.
An ensemble session at least once a week is a great tool to distill culture and best practices in a friendly, yet productive, environment. It also allows different skill levels in different areas to cross-pollinate. A junior developer can grow their confidence in the codebase much faster without needing to interrupt another team member, while a senior developer can instill the practices they’ve learned over the years without needing to write extensive documentation.
Leveling out skills also means that you are no longer reliant on one single key developer to work on a piece of software. There is thus no bottleneck and there’s a higher contingency when one of the ensemble is not available for some or other reason. The work can go on without requiring one specific person to be present, which in my opinion is a huge benefit.
5. Improved communication
By far the biggest benefit in my view, however, is the improved communication that an ensemble session requires. Because the driver has to take instructions from the navigator they have to practice their active listening skills, while the navigator has to learn to become a better teacher and putting words to often abstract ideas in their minds.
Although it might be faster and easier to just do it yourself in the short term, it is always faster and easier to upskill the person for long-term gains.
By far one of the biggest obstacles in leveling up skills from a junior developer to become more senior is having someone explain how to do things within context. I have seen so many times how really clever developers work become obsolete simply because they are unable to explain it to another and it is easier to redo it than to figure it out.
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.
1. Understand the different roles
First and foremost 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 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. 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.
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.
We use mobti.me to keep track of who is which role and ensure that we give everyone a fair and equal chance behind the keyboard. By default the time box is set to 5 minutes, which means that even if you are brand new to coding, it is possible to sit through 5 minutes of discomfort.
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.
3. Limit contributors
From my own experience and talking with other practitioners who have used ensemble programming in different setups, like any team, the sweet spot is 3–5 participants at a 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 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 would 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.
4. Pick the right 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 problem-solving. There needs to be a reason to have collaboration in other words.
If it is something like grind work that just needs to get done, it would most probably be more productive and engaging to just go do it. However, it might be much more fun to take boring and repetitive grind work and do it together in other cases. It really depends on the task at hand and the personlities within the team.
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.
5. Get the right tools
There are a growing number of tools available to enable code sharing sessions. We mostly use VS Code Live Share which is good except for a few annoying bugs, and IntelliJ is a very good alternative that we’re currently experimenting with which is a bit better with permission management. They also have a built-in call option which allows you to use one tool rather than having to use another video conference tool and the code editor.
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.
You will also need a timer. As mentioned earlier, we use mobti.me and there is a range of options available so pick one you like most. You can even use google timer or your phone if you don’t have any other timer.
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.
6. Make it voluntary
As a professional “playoneer” (someone who understands play and the mechanics of play and uses it as a tool for creativity and innovation), 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.
To get maximum buy-in and participation it is essential to make these sessions voluntary. The law of two feet should always apply which gives people the freedom without any negative consequences to leave the session if they feel they are not contributing or getting anything out of the session.
7. 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.
This is the one requirement that can not be omitted. Even if you break all the other rules, having the space to reflect and learn will probably lead you to include all the rules gradually and so much more.
Agility is the ability to respond to change. 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 it. Ensure that there’s not too many actions and that the actions get checked off before adding new ones.