Why Ensemble Programming?

Driver’s Role - The Driver operates the ● When the Driver is more advanced,
"All the brilliant people working on the same keyboard to input/implement ideas made by Navigators then give higher-level
thing, at the same time, in the same space…." the Navigator(s). instructions, like “commit” or “move that
– Woody Zuill method to the parent class”. Over-navigating
Navigator(s) Role - Navigators direct the entails too much direction, and
“Ensemble Programming is a continuous Driver. This allows everyone in the ensemble to under-navigating too little.
integration of ideas.” – Joshua Kerievsky interact with the Driver. If that causes chaos, ● Don’t sit and watch the Driver work. Everyone
have one Navigator give directions to the learns and contributes in an ensemble.
“Context Debt will accrue interest, pay it early Driver– the Navigator serves as the voice of the
and often.” – Igor Poltosi whole ensemble. Newbies to ensemble Ensemble Responsibilities
programming can ask how best to navigate. ● Treat everyone with kindness, consideration,
There are many ways to ensemble successfully. and respect
In general, there is one computer, a keyboard Driver Dos & Don’ts ● Plan, discuss, research, and work out ideas
and mouse, one or more monitors, a ● Drivers don’t navigate. If the Driver is the on the whiteboard
whiteboard, one Driver, and one or more only one who knows what to do, they should ● If a Driver begins to navigate and drive
Navigators sharing a work environment like the navigate. In general, SMEs navigate. simultaneously, someone in the Ensemble
one below: ● Each Driver can share how they prefer to be should call them on it. It’s a no-no.
directed, including asking questions about ● The Ensemble continues as people join or
intent, location, and details. Ultimately, leave
navigators must communicate in a way that ● Stakeholders, Managers, Subject Matter
allows the Driver to understand and take Experts, etc. are welcome to join and are not
action. required to drive or navigate.
● If no one is navigating, the Driver must stop
typing. Leaving and Joining - It is fine for people to
Image by Mark Pearl leave or join the Ensemble. If they are a Driver,
Navigator(s) Dos & Don’ts they relinquish that role to the next person in
Ideal Ensemble Size The whole team, ● Navigator ideas pass through the Driver’s line and the ensemble will adjust its rotation
consisting of 3-5 people is ideal. Beyond 5 ears and hands into the keyboard and code. schedule.
people, an ensemble may encounter difficulties ● Navigators must pay attention to the Driver’s
keeping everyone engaged. Doing frequent skill level. If the Driver needs word-by-word Switching Drivers - A Driver switchover should
rotations can address this. instructions, the ensemble must explain in only take a few seconds. Switching Drivers is
detail what the Driver needs to do. easiest when the Ensemble has the same setup.
If individuals in the Ensemble have preferred good design skills won’t magically produce
tools and settings, consider using tools like Bias for Action - When discussing how to solve good designs. To improve the design, the
mob.sh so folks can have their own IDE a problem, get out of the abstract as soon as Ensemble should get expert help.
settings.. possible. ● Conflict between team members - In order
● Do not argue for more than 5 minutes. to be a well-functioning Ensemble, everyone
Remote Ensembles - Here are some setup ● If there are multiple ideas just pick one and must embrace kindness, consideration, and
suggestions for successful remote ensemble try it, then try another if necessary. respect as the way of working.
programming sessions: ● Keep the Ensemble moving with this quote
● For collaborative keyboard and mouse from Brian Marick: “An example would be Don’t Stop the Work - The Ensemble can
sharing, there are several tools available: handy right about now”. temporarily delegate a member as a researcher,
CodeTogether, Code With Me, LiveShare, to find solutions to something they cannot
Tuple, and others. Value of Ensembles - When done well, easily figure out. Meanwhile, the Ensemble can
● We also use mob.sh to share the code ensembles help a team: work elsewhere in the code. It is important that
repository when our IDE setup is different ● Deliver solutions faster by increasing focus, people feel comfortable asking questions, but if
across the team. building skills, and sharing knowledge. the Ensemble is moving slowly due to a lot of
● For screen sharing several tools are ● Produce better quality code because the questions, it is better to set aside time outside
available: Zoom, Gather, Microsoft Teams, ensemble reviews the code as it is being of the working session to answer questions.
TeamViewer, and Webex to name a few. written. Fast throughput is an important goal.
● There are several whiteboard-type tools for ● Cross-train its members ergo removing
story maps, discovery trees, and high-level knowledge silos and removing context debt. Invite Experts - If an Ensemble gets stuck, they
design discussions. Some that stand out are ● Feel the pain of tedious tasks. This is good, may invite an expert to join and help resolve a
Miro, Mural, and Figma. as it biases toward fool-proofing and problem. Be sure it is an invitation and not a
● Perhaps two most important items are a automation. demand (the guest is not required to drive).
comfortable chair and a great stainless steel ● Deliver results faster by reducing the team’s
container to stay hydrated. Hands down we “work in progress” and eliminating delays Resources
recommend the YETI brand. from handoffs with the whole team present. ● Mob Programming – A Whole Team
● A high-quality camera and mic are a must. Approach, by Woody Zuill and Kevin
Pitfalls - A poorly functioning ensemble will Meadows
Timing and Breaks produce value slowly. The following are some ● Code with the Wisdom of the Crowd: Get
● Use an automated timer (e.g., Dillon Kearns’ signs of poor ensemble programming and what Better Together with Mob Programming, by
Mobster App) to initiate role changes and do to if you observe these behaviors: Mark Pearl
breaks. ● Excessive discussion or arguing - Run some ● The Mob Programming Guidebook, by
● Try the Ping-Pong collaboration pattern or experiments, then decide which the Maaret Pyhäjärvi
switch roles every 7 minutes on average Ensemble prefers. ● Mobster - free tool that helps teams manage
(beginners should switch every 2-4 minutes). ● Zoning out - Take a short break with an rotations and breaks (http://mobster.cc)
● The whole ensemble should take regularly agreement to focus. Take breaks more often. ● Tuple - remote pairing & ensemble app
scheduled breaks. The Pomodoro method, a ● Ignoring roles/timers - Team members (https://tuple.app/)
proven method of taking regular breaks to should hold each other accountable
increase efficiency, suggests taking breaks ● Producing poor designs or not valuing good
every 48 minutes. design - An Ensemble that lacks people with