The Course of Least Resistance

One of the challenges in coaching is how to help people internalize and “own” a new technique or method, after they’ve experienced it and decided they like it. Often, people use the new technique or method as long as the coach is present to encourage them and remind them. As soon as they’re on their own, they tend to revert to the familiar.

How backsliding happens

You’re working with your coach and test-driving code. You aren’t accustomed to test-first development, and you have to pause and remind yourself to write a microtest that will cause the necessary production code to ask to be born. You’re doing fine with the coach on hand, but soon after she leaves you’re back to writing production code first.

It’s understandable. You write a microtest, get it passing, do a little refactoring. You write another microtest and get it passing. Now you’re on a roll. Your mind is racing ahead to the next steps in the emerging design. The production source file is already open in the editor. Your hands are already on the keyboard. The next bit of logic is at the front of your mind.

The easiest thing you could possibly do at this point is to keep on writing production code. So you do. After a few minutes, you realize what you’ve done and symbolically slap yourself on the forehead. Maybe you even say “Doh!” out loud. Now you’ve got this big pile of warm steaming code, no test coverage for it, and an error somewhere in the pile. It’s turning into another wonderful day in the debugger.

The value of a friendly reminder

It’s hard to change habits when you’re on your own. It’s a little easier when there’s someone there to remind you.

That’s one of the benefits of collaborative work. The primary value of collaborative work is that it reduces (and sometimes eliminates) delays and “waits” for answers (How is this field used in this interface?) and services (Need a test VM spun up). But a secondary value is that there’s always someone around to remind you to do the right thing.

And the value doesn’t come from one Big Thing. It comes from a thousand Little Things.

• Hey, remember our naming convention for variables. Oh, right. Thanks.
• Where’s the test case that’s forcing you to write that code? Oh, right. Thanks.
• Still doesn’t compile! I don’t see the problem here! Looks like you have a dash instead of an underscore. Oh, right. Thanks.

What’s collaborative work?

When I say “collaborative work” in the context of software development and delivery, I’m thinking of two techniques in particular: Pairing and mobbing. Pairing means two people working together on the same task at the same time. Mobbing means a group of people (more than two) working together on the same task at the same time.

In addition to the general benefits of collaborative work (or maybe part of same), when you start to slide back into old habits, there’s someone participating in the task with you who will remind you to do the right thing. It’s amazing how much time that saves.

From “possible” to “the easiest thing”

Some teams that are new to collaborative work and lightweight development methods assume that it’s sufficient to make a technique approved or available, and that team members (who have no prior experience with the technique) will be able to make well-informed judgments about when to use it. This doesn’t appear to work out very well, for some reason. Go figure.

Making the “right thing” (per the team’s consensus and/or the coach’s guidance) the easiest thing helps people reinforce good habits.

The most fundamental thing to start with is to get collaborative work going. Then, the team members will be in a position to help each other develop habits around other good practices. But here’s the trick: Collaboration has to be the easiest thing for people to do; it isn’t sufficient for collaboration merely to be “possible” or “approved” or “encouraged.” It has to be the course of least resistance. That is the course people follow almost every time.

Anecdote 1

I remember one organization where the development teams wanted to use pairing. Developers sat at long tables in a big open space (not a “proper” team room layout, just a conventional open office plan). To make pairing possible, management set up workstations at the end of each long table with a standard development machine, two monitors, two keyboards, two mice, and two chairs. Then they invited developers to pair at will.

Nothing changed. No one ever used the workstations. Developers said they were interested in pairing, but no one ever did. The easiest thing to do was to sit in one’s usual place and work solo. The solution was to reorganize the physical work space into proper team areas. Then the easiest thing to do was to sit at a workstation designed for two people.

Anecdote 2

Another organization had a similar issue. The team wanted to “pair more.” In every retrospective, they said they wanted to “pair more.” In every retrospective, they said they had not “paired more” in the previous iteration. They were sad. Their team work space had a big table with eight chairs and eight workstations. People were physically close together and could see each other’s monitors, but they didn’t pair.

One day after work, their ScrumMaster and I removed four of the workstations. The next day, everyone paired (starting when team member #5 showed up). No one had to be told. It was the easiest thing to do.

Anecdote 3

On an organizational transformation engagement for a large client, I was facilitating a workshop with one of the teams to introduce test automation. We were in a large conference room with one laptop connected to the overhead projector. I had done a demonstration of Cucumber (this one, actually) and we had worked through a number of steps in a fairly non-technical Ruby introduction (this one, actually).

The team members and I realized that the nature of their work didn’t really lend itself to this sort of test automation. Then their lead Business Analyst had an idea. She asked whether Cucumber could read Microsoft Excel files. Well, sure it can. It’s Ruby. It can pull in any Ruby gem that supports whatever it needs to do. There are gems available for working with Excel files. Then she asked whether Cucumber could access IBM 3270 screens. Well, sure it can. There’s a gem for that.

It turned out that this team had to perform a fairly tedious, repetitive, manual task several times per week. They received an Excel file from a business unit, and they manually entered data from the spreadsheet into a CICS application.

The Business Analyst took command of my laptop and used her minutes-old coding skills to put together a working proof of concept solution to read the Excel spreadsheet and load the data into the CICS application using Cucumber. The rest of the team helped her in real time. They were all sitting in the same room and there was exactly one workstation. It was connected to the overhead projector so everyone could see what was going on.

You recognize what they were doing, of course. They were mobbing. They didn’t know it had a name. It just happened to be the course of least resistance for them to eliminate a tedious manual task that none of them enjoyed. If you’re not familiar with mobbing, please note that the person at the keyboard was not technical. The person at the keyboard can be anyone on the team.

The moral of the story

If you want your team to do something, make it the easiest thing they could possibly do. Otherwise, they’ll do whatever else happens to be the easiest thing they can possibly do.