Rules

1. Take breaks

Tools like Pomodoro help remind teams to take breaks, but sometimes team members are accustomed to having to always be at their desks so they feel guilty stepping away from an ensemble, encourage regular breaks and encourage people to step away when needed.

By working on a TDD approach a rotation after every PR and merge is a great opportunity to take a break

Having a moment away from your desk can also often provide you with a clear head to think of a solution to a problem. Take breaks. It works.

2. Watch out for the Hare.

In an ensemble, there is one “driver” at the keyboard, and the driver’s job is to do what the navigator(s) say. In a strict driver/navigator ensemble, there is one navigator and everyone else is an advisor.

Either way, the driver is not in charge. The driver’s job is to operate the machine only. The rest of the group decides what to type, what to move, what to delete. The driver executes the will of the team so that every idea goes from one person’s brain through another person’s hands.

3. Find the right level

Some people are very familiar with programming, refactoring, testing, and navigating the IDE. Complex commands can be delivered in shorthand like “reorganize the imports,” “extract this to a field initialized in the constructor,” and “move this block to a function in class Z.”

Other drivers may have to be told specifically what hot keys to press (“press command-alt R”) or what text to type.

It’s important for the navigators to not direct an experienced driver as if she were a novice, or a novice as if she were expected to operate as an expert.

We tell drivers to lean back with arms crossed when they are overwhelmed or micromanaged, and likewise when the room is deliberating and not giving instructions. Then when the room takes notice, to ask for what they need from the room.

Sometimes a driver’s time will lapse without the driver entering anything into the computer. This is okay. Sometimes 7-15 minutes of thinking will help the team make a better decision, but seeing the driver with arms crossed is a sign that we need to get to a point of action soon.

4. Argue in code

Developers think in abstract ways about problems. It’s a super-power of programmers. We also have a tendency to have our own views and opinions, and to weight our values and practices differently and so we deliberate as a group. We do this quite a lot. It’s a good part of the process and ensures that our best ideas make it into the code.

However, as people disagree they can argue about the abstract nature of a problem, often the easiest thing to do is make it concrete and prove it with a test. Concrete cases are easier to reason with.

5. Refactor

Once the tests are passing, there is an opportunity to refactor following the red, green, refactor approach. Simplify your code, follow DRY and SOLID principles if appropriate and then ensure your tests still pass before pushing your changes.