Over the last few articles, we’ve discussed the value of asynchronous work to a remote and distributed agile team. If by any chance that made you too enthusiastic, we’ve discussed some of the reasons your organisation or your team may resist this shift. In this relatively shorter article, I’d like to share with you four ideas that may help you prime both your broader organisation and your team for the change. We’re not yet at the level of an implementation checklist and a playbook for individual practices will follow in due course, but for the time being, consider this as a framework to help align your team. Enough said. Let’s get right into it.

Focus on value

Like anything else we do in agile software development, the notion of “value” is at the centre of this shift to asynchronous work as well. Let’s get one thing straight - asynchronous work is not the goal. It’s a means to an end: an end that wholly synchronous ways of working cannot achieve. At the risk of repeating myself, let’s look at a summary of benefits.

The first step in introducing change on your team will be to align on these elements of value. The more of these benefits the team cares about, more they’ll be open to change.

One trap I’ve seen myself fall into, even when I’m consulting professionally, is making binary judgements. You may identify with this tendency - something is either perfect or rotten. There’s nothing in between those two extremes. As we embark on any journey of change, I think it’s important to acknowledge that we may never be perfect. This is life in perpetual beta - you and your team will get better with time. Asynchronous work that’s judgemental and unkind somehow belies its central intentions - to build flexible, inclusive teams that value deep work.

So the key to plotting this change is to think of it as a spectrum. Thankfully, James Stanier did all the hard work for us defining this spectrum in his book “Effective Remote Work”. I’ve just flipped the direction of his spectrum. You see, agile teams value the approach of “shifting left” when testing. The idea is to catch defects earlier in the development process. It can confuse teams to shift left for one thing and right for another; so I prefer this direction of the spectrum. 

The image is self explanatory - as you go from right to left; you go from a fully synchronous medium to a fully asynchronous medium. And just as you don’t want to run an entire project just on a wiki, you don’t want to communicate only on video calls all the time. Communication methods on the right side of the spectrum are the ones I characterise as “temptation comms”. They are easy in the short term, but they have fewer long term benefits. As you traverse left, communications get tougher in the short term, but have longer term benefits - the kind we’ve discussed earlier. I call them “investment comms”

To quote Stanier with a slight modification;

Using the spectrum as a reference will help your team co-own the change as you integrate asynchronous ways of working into your software development process. Coupled with the benefits you’re looking to achieve, this gives you a sense of direction.

Make a Ulysses pact

There’s a story in Greek mythology about the Sirens - a band of women singers sitting somewhere out on the sea. No sailor could resist the temptation of getting close to the Siren’s rocks once they’d heard them singing. Of course, rocks and old wooden ships were never a fortunate combination - so the next thing to happen was a shipwreck. 

Ulysses wanted to listen to the Sirens, but didn’t want to be shipwrecked. So he made a plan. He stuffed his sailors’ ears with wax and asked them to bind him to the mast as they approached the Sirens. Easy did it - not only did Ulysses enjoy the show, his sailors also steered the ship to safety.

A Ulysses pact is a term used to describe commitment strategies. By binding himself to the mast, Ulysses prevented self-destruction. He also removed the tempting cues for his crew, but we’ll come to cues in a later post. In a similar way, you need to consider what the Ulysses pact for your team is. The pact I recommend is to institute a simple principle everyone can hold each other accountable to.

“Meetings as the last resort - not the first option.” - David Heinemeier Hansson, Basecamp

The biggest obstacle to asynchronous work is meetings, which by definition are synchronous. By agreeing to this basic pact, you can help the team think consciously about the meetings that are absolutely necessary.

All said and done, you can’t be a zealot. Imagine a system in perfect balance. On one end, you have asynchronous collaboration with a certain value that it brings. On the other, you have synchronous interactions and their value. As we’ve discussed with the spectrum of synchronousness, this isn’t a zero-sum game. You choose a certain interaction by assessing the value you’re looking to get out of it. My argument for asynchronous agile stems from the fact that most teams are too far on the right of the spectrum. That doesn’t mean I see no value in being on the right sometimes!

There are a few trade-offs you make when you decide the nature of your interaction.

• Thoughtfulness vs. speed. Writing up a document is slower than brainstorming on Zoom. Waiting for people to think things through and comment on your document slows things down even further. Including people with flexible hours may not optimise for speed. This is classic System 1 vs System 2 in action. In return for slowing things down, you optimise for thoughtfulness instead. 

• Depth vs. breadth. A side effect of speed is that you cover more ground in a short period. Taking that metaphor further, it’s easier to cover several miles in an hour than it is to dig a few feet in the same time. Similarly, synchronous interactions allow you to cover a wide range of topics in a short time, but if you want depth, you’ll need to be more asynchronous.

• Productivity vs. connectedness. Even the most ardent advocate of asynchronous work will tell you that while it’s more productive to have time for yourself, it can get isolating after a while. You don’t need to kid yourself. We’re all human and we want contact with our friends and colleagues from time to time. Synchronous interactions offer that connectedness.

• The future vs. the moment. Last, there’s the value that James Stanier calls “permanence”. With the focus on writing things up, asynchronous work helps you create assets and artefacts for the future - be it for reference-ability or for onboarding. Synchronous work, on the other hand, is all about the present moment. If you need an instant solution or urgent help, you’ll need to be synchronous!

Anyone who’s watched The Karate Kid can’t forget the lovable Mr Miyagi. There’s a quote of his from the movie, that I love.

“If you want to go fast, go alone. If you want to go far, go together.” - African proverb

Without buy-in from your team, any change you try to introduce won’t go very far. So I urge you to spend time working with your team to identify the value you’ll get from being more asynchronous. Any change that looks too daunting, won’t go too far either. Think of small steps and quick wins to get you started. Commitment strategies will help and so will a pragmatic, balanced approach. 

Whatever you do, don’t be a hard-nosed zealot. Instead, take a part-advocate, part-guerilla approach. Be an advocate to make your case with bosses and co-workers. This’ll help you garner the support you need. Be a guerrilla to change the things you have influence over. Every little win will help you justify subsequent experiments. 

And most importantly, be ready to move from the whiteboard to the trenches. A successful async-first team doesn’t need hand-waving leaders. You’ll be valuable to your team when you can get into the details and help your colleagues out when necessary. Showing them how to execute a practice in an asynchronous fashion. Create an environment conducive for change. Be a role model with your own way of working.

This article brings us to a logical point where we can start thinking about ways and means to be more asynchronous on distributed, agile teams. In upcoming articles, we’ll address various communication and collaboration practices on your team, so you can pick the improvements you want to make.