By
Bob Allen.
If this sounds like your inner voice, you are not alone.
So OK, let’s do the simplest thing that could possibly work, in the
simplest way that could possibly work and keep our sanity.
Cyber-Dojo is the enabler
I’ve been using for more than 6 years to help
bring people together. Until recently that was by running a
monthly coderetreat,
where we choose any language plus any test framework we
wish, and we pair-program with a different pair partner each hour.
Participants are from all over the area, so it’s a great chance to meet
and work side-by-side with people you’d otherwise never get the chance
to code with.
Recent events, the pandemic, presented a new challenge; how to keep the
community coming together virtually. Once again, cyber-dojo made this
pretty much friction free. In late March, I got to mob program with people
from all over the world for 2 hours at a time thanks to
Woody Zuill.
Last week, I hosted five days of two mobs per day, on three continents.
The experience has been totally energizing and I’ve grown my network
while having fun with friends both new and old.
Let’s Mob - Remote
Here’s how mobbing works when your sat together.
Now, here’s how it can work when everyone is remote:
First, in what order the driver and navigator will rotate:
- As a group (a mob) work out the sequence in which the driver role
and navigator role will rotate. Record the participants names in one of the
existing (or a new) documents on Cyber-Dojo. We often put this list into
the feature file when we did an exercise using Cucumber, because it is
where we tend to look whenever we changed to the next thing to do.
- To determine sequencing for anything bigger than say 3-4 people, a trick Woody taught me goes like this: Using the chat feature of the video conferencing tool, ask everyone to enter the name of the city/country they are in. The order in which the names appear in the chat becomes your sequence for rotating the driver role.
This has the added benefit of giving everyone some context about where their fellow mobbers are.
- For a smaller mob, keep it simple; you can just enter people’s names and put that in the chat or in a document that everyone sees throughout the exercise.
- The simplest way to rotate both driver and navigator is to have the current navigator becomes the next driver. This helps them to be focused when they become the driver.
- Overriding the sequence for good: To help draw out someone who may be nervous about participating, make the
least experienced member of the mob the first driver, and an
experienced person be the first navigator. This has multiple benefits:
- The least experienced person gets the support they need from an experienced
navigator (The rule in mobbing is: “For an idea to go from your head into the computer,
it must go through someone else's hands.”
- Also, because when the least experienced person rotates off the driver’s seat,
they now get the entire rotation to observe before it’s their turn to navigate.
How the driver change occurs:
Here are some options for limiting how long it takes to change drivers (changing drivers can be clumsy
and interrupt the flow if it takes too much time):
- Least cost: Don’t change the driver at all, i.e. no driver hand-off. Only rotate who is navigating.
- Or, only change the driver at a rest break; fewer hand-off are less frequent,
- Or, if possible, use the video conferencing app to transfer control to the driver.
This way a single computer’s browser is controlling tests and the code, but, who is
controlling the browser on that compute is what rotates.
Note: For this option network latency can be difficult if some participants have
not-so-good bandwidth or the mob is spread across long distances. In that case
use the Hand-off-the-browser-protocol* to change drivers. Also, keyboard
differences (Mac vs. Windows or Dvorak vs. QWERTY may be handled badly by the screen sharing software)
*Hand-off-the-browser-protocol:
After beginning an exercise, use the chat feature of your video sharing tool to
give everyone the full URL to the Cyber-Dojo exercise. Make sure everyone who is going to be
an active participant actually opens the URL in their browser. Make it clear that only the driver
is allowed to hit the test button in the cyber-dojo upper left screen. This is important because
that action “checks-in” whatever the state of all files currently on that individual’s browser.
Now, when the time comes to switch drivers, make certain the current driven has
checked-in any changes by hitting the test button. Only then can the next
driver refresh their browser and be assured of being up-to-date. Have the
new driver confirm the version displayed by Cyber-Dojo in their browser with the
prior driver. In this way the hand-off can be confirmed.
Before you begin actually coding, the mob needs to make some choices:
- If it’s just a single mob,
- then from the opening page of cyber-dojo select “I’m on my own” followed by “create a new exercise”.
You’ll be looking at a list of exercises/katas. There are just under 50 at present, each showing
instructions on the right. Select one of them and hit next.
- now choose a language and test framework, each showing freely given starting test code to the right.
You may notice a hint of Douglas Adams in the tests regardless of the language or framework.
Make your choice and away we go…
- If you have too many people to stay as a single mob (rule of thumb: cap at 8-10 people*) you
may want to use break-out rooms in your video conferencing software (Zoom does these well). In
this case, each room becomes a separate mob and uses the practices described above in #1.
*BIG mobs take a l-o-n-g time before the rotation comes back around and people’s attention tends to drift when this happens.
On what basis to change driver/navigator:
The usual practice is to use fixed timer (a simple count-down timer works fine
if there is a designated time-keeper and they remember to start the timer.
Forgetting to reset the timer is a common fail pattern).
Because remembering to restart the timer is common, we found another trigger for
the rotation works for not-new mobs: getting to green.
Upon the current navigator
and driver completing a red-green cycle, initiate the change. Leave the choice
to the next navigator to either refactor or to write another test to force new
behavior. This boundary is a natural one because of the sense of completing a
small change vs. an arbitrary time limit.
That said, if the mob finds itself doing big changes, including large refactoring,
then use a timer with a short period like 5-6 minutes. This will help to influence
the choice to make small changes:
“The simplest thing that could possibly work”.
Here’s a little secret (an Easter egg?)
… not found in the “hotkeys” panel:
- Alt + mouse: Select column or rectangle of text. (Shift + up/down can also do this, but not in cyber-dojo)
- Ctrl + right/left: Seek beginning / end of next word. Hold Shift to select while seeking.
Typing, cut/paste, and seeks apply from current positions.
These are the same as you will find in the JetBrains products.
Many thanks to Bob for this guest post.
