Ensemble programming and ensemble testing are a collaborative way of working in which four to six people program or test together: one person operates the keyboard, the others think aloud and give directions. Thinking and doing are deliberately kept apart. That makes tacit knowledge explicit, spreads knowledge between testers and developers, and produces more creative results than working alone.
Key Takeaways
- Ensemble testing strictly separates thinking from doing: one person types only when told what to do, while the rest of the team thinks out loud and turns tacit knowledge into explicit knowledge.
- The ideal ensemble has four to six people. With fewer, individual voices get lost; with more, the session drags.
- Ensemble formats win over skeptics more easily than pair programming, because a group puts less personal pressure on people than working one-on-one.
- Testers don’t have to become programmers in ensemble sessions. They build enough understanding to ask better questions about testability.
What Ensemble Programming and Ensemble Testing Are
In ensemble programming, a whole group works on one task together instead of splitting it up. The same goes for ensemble testing. One person sits at the keyboard and mouse, and the rest of the group sits around them and thinks out loud. The goal is sharing knowledge, building the team and learning together, not finishing faster.
Thomas Much describes the format as the next step after pair programming, which he spent years coaching. Instead of two people, four to six work together. The practice goes by several names: mob programming, team programming, software teaming. When the focus is on testing, people call it ensemble testing.
What makes it appealing is that different roles share the same space. Developers, testers, and sometimes architects or people from the business side sit together and produce something concrete: code or tests.
The Most Important Rule: Separate Thinking from Doing
The core principle of working as an ensemble is keeping thinking and doing apart. The person at the keyboard only carries out instructions. They don’t decide what happens. The group does the thinking.
That person is called the typist. They type, click and enter values, but they don’t act on their own initiative. If nothing comes from the group, they ask: Where should I click? What amount should I enter? Thomas calls this a “smart input device.” The typist can ask a question at any point if something isn’t clear, and can insist that the group agrees before moving on.
Thinking out loud makes tacit knowledge explicit. Why does someone enter a number with a period instead of a comma? Which upper and lower limits matter in this test? When you work alone, decisions like these stay invisible. In an ensemble, they get said out loud and discussed.
Why Nobody Gets Overwhelmed
Nobody at the keyboard needs any particular skill, because the intelligence is in the room. Someone who can’t program may only type single characters at first. That evens out quickly: in between turns you spend twenty minutes watching what the others type and pick up how things work.
This is where mixed teams benefit most. Testers pick up an understanding of development along the way, and developers build up testing knowledge. Nobody has to take over the other role completely.
“When I say, I didn’t get that, please explain it in more detail, there are always one or two people in the room who say: I’ve always wanted to know that.”
(Thomas Much)
It works because an ensemble is a safe space. Supposedly stupid questions that nobody would dare to ask one-on-one come more easily in a larger group. Thomas has seen a CEO, team leads and project managers join in, just to find out whether it really is that easy to take part.
The Ideal Group Size for an Ensemble Is Four to Six
Four to six people is the ideal size for an ensemble. With fewer, you run short of ideas and the dynamic tips over.
In a pair, one person usually dominates while the other gets drowned out or doesn’t dare to ask. Even with three, someone often gets sidelined as soon as the other two agree. From four people on, the voices balance out and the group moderates itself. Even the loudest voice has to be quiet sometimes, because it’s their turn at the keyboard.
More than six people and things start to drag. Thomas once worked with twelve people and rotated every two minutes. It was fun, but the group was really too big.
Give It Enough Time, or It Won’t Work
An ensemble session needs time, and rushing kills it. Under pressure, nobody dares to ask questions, and the safe space is gone.
Thomas recommends that teams starting out block two to three hours a week. If the task is done early, even better. Use the rest of the time to make the code easier to maintain or to automate another test. The time fills itself.
Experienced teams can get by with an hour, as long as the setup is ready and the machine is running. When you’re starting out, though, it’s better to plan too much time than too little.
The person at the keyboard changes at short intervals, every five to ten minutes. A timer enforces the timebox so the handover happens without debate. Tech enthusiasts like to hold on to the keyboard and don’t like to let go. The timer takes care of that.
How Ensemble Work Differs from Pair Programming
It’s easier to win skeptics over to ensemble work than to pair programming, and that comes down to the setting.
Thomas passes on a comparison he heard from an agile coach: pair programming is like a date, where the two people have to click perfectly or it gets exhausting. Ensemble work is more like a party with friends, more relaxed and with less at stake. That makes the format more durable in day-to-day work, and on average teams use it more often.
In practice, teams fall somewhere between two extremes. Some try it once and forget about it. Others work in ensembles a lot. Most end up with a healthy mix: in the daily, they agree on what they want to tackle together that week.
Architecture Is a Team Sport
From an agile, continuous point of view, architecture isn’t a job for specialists but for the team. The team makes local design and architecture decisions. Central architects facilitate the whole thing and make sure the company doesn’t drift apart.
If architecture is decentralized, it belongs in the ensemble just like code and tests. The distinction is simple: what’s hidden in the code is design. What can be observed from the outside is architecture.
Where architecture teams work more separately, it pays to bring them into sessions regularly. Architects who make decisions centrally then see what their guidelines mean when someone has to implement them. That experience gives them new ideas for setting more suitable guidelines.
The same goes for business departments that complain about getting too few features. Once you bring them in, they understand what makes development hard: features that aren’t clearly specified, or contacts who are rarely available.
An Ensemble Meeting Produces Code, Not Minutes
The most common objection from management is: four people for two hours, shouldn’t they be working? Thomas turns the argument around. Managers never sit alone in meeting rooms either. They get together because they want to achieve something.
The difference is the result. At best, a management meeting produces an agenda or minutes. An ensemble session produces tested code with a clean architecture. Exactly what a development team needs.
The format came out of Woody Zuill and his team more than ten years ago, at first as an under-the-radar project that management didn’t know about. The explanation they gave their bosses was simple: we’re having a meeting. It’s just that this meeting produces code and tests.
How to Set Up Your First Ensemble Session
Start in person, not remotely. In the same room you get facial expressions, gestures and shared laughter, and people don’t talk over each other. Remote work needs screen sharing, tooling for the handover and a lot more discipline. Save that for later.
The key success factors for getting started:
- Room: not too small and not too big, so it doesn’t feel anonymous.
- Participants: four or five colleagues who actually want to take part.
- Preparation: one person gets the setup ready in advance so the machine is running. If the group has to wait half an hour first, the enthusiasm is gone.
- Layout: the computer on a standing desk, everyone else sitting comfortably around it. Whoever’s turn it is gets up and walks to the computer. That small movement separates doing from watching.
- Roles: the typist holds back and doesn’t act on their own initiative. The group thinks out loud.
- Timer: rotation by smartphone timer, so the handover happens without discussion.
Coding katas, small practice exercises, are a good way to start. After that, move on to real work quickly so the format proves itself outside the training room too. If you want to dig deeper, there are videos by Woody Zuill on mob programming and software teaming and by Lisi Hocke on ensemble testing.
Frequently Asked Questions
Does collaborative testing in a group save time?
No, speed isn’t the goal. Ensemble testing and ensemble programming focus on knowledge sharing, team building, and collaborative learning. A group of four to six people works on a single task together, rather than dividing it up. The benefit lies in the fact that developers, testers, and sometimes architects or subject matter experts produce something concrete in the same room: code or tests.
Why can’t the person at the keyboard decide for themselves what happens?
Because the separation of thinking and execution is at the core of the format. The typist types, clicks, and enters values, but doesn’t act on their own initiative; instead, they ask: “Where should I click?” “What number should I enter?” Thomas Much calls this a “Smart Input Device.” This brings to light decisions that remain invisible when working alone, such as boundary values or number formats.
Do testers need to know how to program to participate in ensemble programming?
No. No one at the keyboard needs to know how to do anything, because the intelligence is in the room. Those who don’t program might start by entering only a few characters and then spend twenty minutes watching the others work. The goal isn’t to turn testers into programmers, but to give them enough understanding to ask more informed questions about testability.
Does this format work with just two or three people?
Not well. With just two people, one usually dominates, while the other gets overlooked or doesn’t dare to ask questions. Even with three people, one is often overlooked as soon as two share the same opinion. With four or more people, the voices balance each other out and the group moderates itself, partly because the loudest voice is sometimes sitting at the keyboard and staying quiet. With more than six participants, things get tough.
How much time should a team set aside to get started?
For beginners, a block of two to three hours per week is recommended. Experienced teams can get by with one hour, provided the setup is ready and the computer is running. Rushing is counterproductive: Under stress, no one feels comfortable asking questions, and the safe space disappears. If the task is finished early, use the remaining time for maintainability or another automated test.
Why is it easier to win over skeptics to ensemble work than to pair programming?
Because the group setting creates less personal pressure. A comparison shared by an Agile coach describes pair programming as a date where the chemistry has to be just right, whereas ensemble work is like a party with friends: more relaxed and less binding. That’s why this format holds up better in everyday practice and is used more frequently on average. It’s easier to ask supposedly “dumb” questions in a larger group.
How do you justify several hours of group work to management?
By focusing on the result. The most common objection is that four people should be able to get work done in two hours. But managers don’t sit alone in meeting rooms either, and their meetings produce, at best, an agenda or minutes. An ensemble session produces tested code with sound architecture. Woody Zuill and his team launched the format in the early 2010s as an under-the-radar project using precisely this argument.
Is it worth bringing architects or people from the business units into the sessions?
Yes, especially when these roles work separately. Architects who set requirements centrally experience firsthand in the session what their decisions mean in practice and use that insight to derive more appropriate requirements. Business departments that complain about too few features see the obstacles: unclearly specified features and points of contact who are rarely available.
