After reading a lot of long form advice about asynchronous agile, some of you may look for a ‘gimme’. The Cambridge dictionary defines a ‘gimme’ as “something that is extremely easy to do”. So this post is about three things that are relatively easy to do on a software development team that’s trying to be more asynchronous. Consider these as little plays that you can try independently. Sounds good? Let’s get started.

Distributed standups are painful, period. With modern tools there are better ways of getting the value you’d expect from such a meeting. As an individual, you’ll get back a few minutes of your life every day. The bigger benefit? You can share updates continuously, and at your own pace. From a team perspective, you’ll be able to create an audit trail of communication and, of course, plough back the time savings into deep work.

As a team scales, the need for documentation increases in parallel with the cost of not doing it. Daunting as it may seem, a handbook-first approach has many advantages, and will give your team a way to self-govern and self-organise. In this post, I’ll walk you through some ideas about what to include in such a resource and how you can create and maintain it.

It’s clear that we need fewer meetings. This is step one to being asynchronous, and I’d argue that it’s the most important step to take if you want to be a productive, remote-first organisation. In this post, I’ll outline the ConveRel quadrants for you to figure out which meetings you need and which ones you can get rid of.

Before you start tweaking individual practices on your team from a remote and async-first perspective, you need to zoom out and examine your work and communication protocols. So, in this post I want to share with you a few fundamentals you need in place, so you avoid the hyperactive hive mind.