5 XP practices that will make your remote team more effective

By focusing on small increments and collaboration, XP practices like CI, Pair or Mob programming, TDD, continuous refactoring and TCR make remote work easier.

A while ago, Ahmad and I worked in a remote team for about 2 years. When Ahmad joined the team, we were already on our way to eXtreme Programming. XP by the book recommends onsite teams. With a new remote worker, it was tempting to simply abandon XP. Instead, we decided to push it further than 10, and see how it could work for a remote team.

We’ve already wrote and talked about the tools and processes we used to be an effective remote team. It turns out remote programming teamwork is also about the way we write code. (Not a surprise once you understand that everything is part of a single system, Jessica Kerr explains this better than I would)

Context Disclaimer

Let’s start with a small clarification. We were a team spread over 2 offices, with a small, 1-hour time difference. As a consequence, I don’t know how these practices would work in a different setting.

1. Continuous Integration

When we joined the team, it was already doing continuous integration. Continuous integration is now a no-brainer for most teams.

True continuous integration is “integrate all the code, many times per day”. To achieve CI, a team will need to adopt trunk based development and small commits.

Thierry de Pauw – Feature Branching considered Evil from NEWCRAFTS Conferences on Vimeo.

This alone is of tremendous help for remote team members. They can now sync their code very often and stay in touch with what is happening in the codebase. Plus if they get a merge issue when they pull code, they’ll have to call their teammate to sort this out on the spot. This is an occasion for social interaction, which is key to make remote workers feel part of the team.

“💡Pulling the code regularly pushes remote worker into social interactions”

Without CI, remote team members work in isolation on long-lived feature branches. This postpones synchronization until the ‘feature death merge’. That’s not fun and not likely to create regular and easy-going social interactions.

2. Pair or mob programming

With CI in place, we started to do some code reviews. The team then got fed up with code reviews. We finally decided to switch to almost full-time pair programming. (Read the full story of how we switched to pair programming)

“If it hurts, do it more often!”

With Continuous Integration, people would interact at every commit or so. With pairing, people would spend their time together.

“💡With pair programming, remote team members are never ‘alone’.”

When everyone writes the code together, remote team members stay even more up to date with what happens to the codebase.

Pairing also has some other second-order effects:

• People will chat about their personal lives when pairing. This builds connections and creates team-spirit.
• It streamlines the code flow as reviews become unnecessary.

Mobbing?

Unfortunately for us, we did not do real mobbing at the time. The closest we did was team refactoring randoris on our production code.

I have been mobbing with remote teams since. I use it as a coaching opportunity. Remote workers have reported the same benefits as remote pairing.

3&4. TDD and Coding by Refactoring

I have been a TDDer for more than 15 years now… It has become difficult for me to code without TDD. When I joined the team, I used pairing and regular coding dojos to spread the technique. Very soon, the whole team was doing TDD.

Coding by refactoring is about changing the code by small baby-steps modifications. Each one of these baby-steps modification should keep the tests green. It’s like small commits, pushed even further.

I put these 2 techniques together because you cannot code by refactoring without TDD. If you have to wait 1 hour to test a small change, you’ll have a hard time Coding by Refactoring.

If TDD is the enabler, it is coding by refactoring that helps remote teams. When coding by refactoring, tests are always passing.

“💡When Coding by Refactoring, tests are always passing.”

As I explained in “7 Remote pair programming best practices Q&A“, we suffered from connection lag when doing remote pairing. We ended up sending the code every time we switched driver, so that the driver could code on his own machine.

Obviously, if your tests are always green, this is a lot easier. We could commit to master instead of sending patched or pulling from our private repos.

Let’s compare the 2 workflows

Without TDD and coding by refactoring

1. Every N minutes (we used 25 minutes), we would like to switch drivers
2. We send the code over by pulling from our private repo, or by sending over a patch
3. We don’t know what’s working or not. The pair needs to stick together to share the mental load of this work in progress
4. At some point, you might discover that we made a mistake while sending the changes! The later we discover this, the more time wasted.

If this becomes too painful, the group might even stop switching regularly. This when it gets awful for remote team members. Watching someone code for hours on a screen is seriously depressing!

With TDD and coding by refactoring

1. Every N minutes, we need to switch driver
2. As all tests are passing, we commit
3. The new driver can start from a clean state

No mental load, more collaboration, and smaller commits!

5. TCR

Could we push things even further with “test && commit || revert”? TCR is about

• auto-committing changes that pass the tests
• auto-reverting any change that breaks the tests

We never got to try this at the time! The closest we did was trying to stick to ‘always green tests’ during some coding dojo.

TCR goes one step further than Coding by Refactoring by enforcing tests to remain green. It also forces us to code in very small increments. The commit – pull – rebuild dance every 25 minutes was painful. The nice thing about TCR is that it does this for you!

With a bit of tooling, it is possible to integrate TCR in the remote pair or mob programming workflow. Thomas Deniffel shows examples in TCR Variants. We should be able to switch the driver at any moment!

Example: passing a new test

Before, green, commit, switch! 

public class FizzBuzzTest {
+
+    static String fizzBuzz(int i) {
+        return "1";
+    }
+
+    @Test
+    public void returns_value_by_default() {
+        Assertions.assertThat(fizzBuzz(1)).isEqualTo("1");
+    }
+
}

After, green, commit, switch! 

With TCR, 95% of coding becomes refactoring! Passing a new test must be done either with a fake or by refactoring until passing the test becomes easy.

Example: a rename refactor

Before, green, commit, switch! 

public class FizzBuzzTest {
-    static String fizzBuzz(int i) {
+    static String fizzBang(int i) {
         return "1";
     }

     @Test
     public void returns_value_by_default() {
-        Assertions.assertThat(fizzBuzz(1)).isEqualTo("1");
+        Assertions.assertThat(fizzBang(1)).isEqualTo("1");
     }
}

After, green, commit, switch! 

Thomas Deniffel even suggests that we could use TCR to continuously pull the code. This would create a kind of Google-Docs-like collaborative programming.

“💡Is TCR the future of remote teamwork?”

Go eXtreme

We often hear from the “Agile” community that teams should be co-located. Surprisingly, eXtreme Programming practices boosted our remote work. It even seems that the more eXtreme we get, and the more sustainable remote work becomes!

Like the Cucumber pro guys, more and more teams are enjoying remote mob programming. Why not your team? Start today by learning eXtreme Programming practices. All it takes to get started is a regular team coding dojo randori 😉

—-

I’m Philippe Bourgau, Continuous Refactoring Coach

Life is too short for boring stuff! I help software engineers to reach a productive and sustainable pace through continuous refactoring of their code and organization.

Follow my blog with email, or directly from twitter