See updated version of this article here.

2022-03-22: Updates since I first wrote this can be found as bracketed & italic remarks inline.

How I Run Remote Learning Ensembles

The Ensemble (mob) Programming sessions that I've been running for the past few months are centered around improving developer skills in test-driven development (TDD), domain-driven design (DDD), and Hexagonal Architecture, with a focus on taking small, safe steps and frequent refactoring. Since the codebase is Java, it's turned out that all attendees are using IntelliJ IDEA, so an additional focus has been learning its shortcuts and the less common automated refactorings (such as Move Method).

Since the focus is on learning skills and not getting "work" done, I stay out of the rotation, observing and providing guidance and advice along the way. I also serve as the "customer" providing direction on the features being developed. [However, if there's only 2 attendees, I'll drop into the rotation.]

Below you'll find information on how I currently run the Learning Ensembles (much of this was gathered from various sources, some adapted, and some learned by trial and error).

I've found that using GitHub-based hand-offs, with the awesome command-line tool mob.sh, to work better than other mechanisms that I've tried. It allows people to use their own computer and IDE, which means they're not only comfortable using tools that they're used to, but building skills (such as shortcut keys) in their "natural" environment. The downside is that there's a bit of disruption during the hand-off, mainly around the new Driver taking over and possibly having to rearrange editor windows and open up files, though this tends to be less of a problem after a complete cycle of turns.

Roles

We call the person at the keyboard (and sharing their screen) the "Driver" and the person directing them the "Navigator". I've gone back and forth about the role names (e.g., typist, director), and have found that metaphor of getting to a destination with a "Driver" and "Navigator" to be well-suited.

Driver

• When starting your turn, clearly state that you're ready for the Navigator with an "I'm Ready". This is needed so the Driver can do the mob start command (to get the latest code on their machine) and arrange the IDE windows as needed. [We've standardized on a split screen, with the test code on the left, feature code on the right.]
• Driver carries out the Navigator's intent—there is only one Navigator, otherwise the Driver can get confused.
• If the Driver is unsure what to do next, they ask the Navigator for clarification.
  • It's often helpful for the Driver to offer choices "do you want me to extract the whole block, or just line 24?"
• Avoid "Runaway Driver" where the Driver does more than (or different things from) what was asked.

Navigator

• Declares intent at the highest level, only providing more detail if the Driver asks.
  • Start with intent: "extract the loop to a new method named Process Transactions"
  • Provide more detail: "select lines 24 thru 28, use Refactor then Extract Method.
  • Even more detail: "click on the word 'for' on line 24, press the expand selection key a few times, now click on..."
• Avoid micro-managing ("backseat driving") the fixing of syntax errors or typos.
• It's important that the Navigator correct the Driver if the Driver didn't do what was desired, due to either confusion by the Driver, or a mistake by the Navigator.
  • Communication is hard, and the only way a Navigator knows that they were understood is if the Driver did what was desired.
• When the turn is over, inform the next Navigator of what you had in mind. However, it's up to that Navigator to either continue down that road, or try something else.

Onboarding New Participants

• Get their GitHub username
  • Add the username as collaborator to the repository that will be used for the Ensemble
  • They'll need to accept the invite, so do this enough in advance
• Participants will need to install and verify that these work:
  • The mob.sh tool (which requires git)
  • Zoom, especially share screen privileges
    • Do audio check, video check is optional
  • Whatever IDE they're comfortable with
    • Increase font size of IDE to at least 16px for screen sharing readability (sometimes 18px is needed!)
  • Correct version of Java (11 or later)
  • Clone the repository via SSH if possible (this makes it easier to push)
  • Build and run all of the tests
  • Do a test mob start and mob next to ensure privileges are set up correctly

Facilitator Preparation

• Fill out names in the Mob timer
  • We use https://mobti.me
  • Make sure to rotate so folks aren't always in the same order or are navigating the same driver
• Verify participants have accepted GitHub repo invitations
• Verify repository has the latest code (all changes since last session pushed)
• Review retrospective and Mission notes from prior sessions
  • I keep these notes in the same repository as the project code
• Ensure goals (I called this the "Mission") for the upcoming session are clear
• Send a link to the Zoom that we'll be using (even if it's the same one, people like/need the reminder)
  • [I use my Ensembler tool to handle this: see https://github.com/jitterted/mobreg for more.]

The Session

This is based on my experience with 90-105 minute-long sessions [I've found 105-115 minutes—just under 2 hours—better for groups that only get together once a week, or less, in order to remember and/or understand the context]. We cap the size to 5 active participants, with turn times of 5 minutes each.

We have two main roles: Driver and Navigator (as described above). When the turn is over (after the 5-minute timer has expired), the Navigator becomes the new Driver and the Driver goes back into the general crowd. [We now go the other way: Driver becomes Navigator, and Navigator returns to the crowd, as the Driver has the code already in their head/fingers.]

The Huddle

[Added details on The Huddle]

The starting Huddle is a way for the group to sync up and understand where things are and what the next task is. This is important as people haven't seen the code for a week or more (or never!). Once the first Navigator agrees that they have a sense of what to do, the Huddle ends.

During the Ensemble, people can get lost, can disagree on which way to go, etc., and so anyone can call for a Huddle. The timer is stopped and discussion starts. It's important to get back to the code, so if the discussion becomes too detailed (or too abstract!), it's time to see if there's enough understanding to take the next step, without worrying about the steps after that. As the saying goes, "discuss in code" (i.e., writing actual code) is better at demonstrating what approach is better/worse than just talking about it.

Agenda

1. Introduce anyone who's new
2. Provide the mob timer link (if a separate one like mobti.me is used)
3. Remind folks of any Code of Conduct
   • At a minimum, remind them that this is a learning experience and to be compassionate and curious

4. Create (or update) a participants.txt file with the date and start a list with the facilitator's name as the 0th entry. For example:
   

   Session #10 - Friday, May 28, 2021
   ----------------------------------
   0. Ted (@JitterTed)
   

[I stopped putting my name as facilitator, and now it starts with the first participant. Twitter name is optional.]

1. Do one rotation by having each participant do the steps below when it's their turn. The purpose of this exercise it to ensure everyone can share their screen, update their local copy of the repo, and push changes to the repo, as well as an check of their audio and font size. Doing it at the beginning means that it won't interrupt the Ensemble's flow:

   1. Share their screen (I make sure that Zoom allows participants to "steal" the screen sharing from the current sharer)
   2. Execute a mob start, once it completes...
   3. Type their name in the participants.txt file (if it doesn't show up, or is missing other participants, you know something's not quite right), e.g.:

      Participants from Ensemble #50 on March 4, 2022
      -----------------------------------------------
      1. Hoffman
      2. Moxie
   

   1. Execute a mob next and once it completes...
   2. Announce "Ready for next DRIVER"
   3. Next driver takes over and repeats from step 1 until everyone has had a turn

2. Explain/review the mission for the session

   • I keep this in a text file in the same repository as the project code

3. The Team does a "huddle", where they discuss the mission, make sure they understand it, and define the next task or two.

4. The first Driver shares their screen, does a "mob start" and when complete declares "I'm ready"

   [Usually they'll start by running all the tests]

5. The Navigator provides instructions to the Driver

6. When the turn is over (the timer has gone off), the Navigator relays their intent (what they were trying to achieve) to the next Navigator

   [If the Navigator/Driver are almost done with a task, I'll usually let them finish it before moving to the next person.]

7. Things that need to be done (delete that test, rename that class, fix that flaky test) are dropped into chat

8. Side-comments about the work are also dropped into chat

9. After each full cycle (everyone has taken their turn once), the facilitator runs a "mini-retrospective", if the ensemble feels that things are in a good flow, the mini-retro can be skipped.

   • Often the 2nd time around, folks feel the need to mini-retro to regroup and gain perspective.

   [With a more experienced group, I've not found this necessary, as folks seem to learn to call for a Huddle as needed]

10. The final turn ends when there's 15-20 minutes left in the scheduled ensemble time.

11. Conclude with a retrospective, where each person in the rotation provides thoughts, observations, things they learn, etc., until everyone has run out of things to say. Then, things to do more or less of, what went well/not so well, etc., are noted in an outline or mind map.

12. Facilitator shares observations (the more specific and concrete, the better), such as "I noticed it took 3 turns to finally get from red to green" or questions, such as "how did it feel to leave have that test continue to be flaky", or "was anyone uncomfortable with the poor code formatting in that method?"

13. Session ends with cleaning up of the pending tasks, collecting undone ones from chat, checking off those that are done, etc.

14. Everyone waves goodbye!

---

Note that we have changed how we run the Ensembles over time, because of things brought up in our Retrospectives. I'll follow up with a post on what's changed since the above was written. One non-trivial change was the order of Driver-Navigator. When we swapped that order, we found less of a need to "hand off" intentions.

Stay tuned!