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.

It’s time to lay out the framework for change. It all starts with values and guidelines. In addition, the team needs to reflect on the work they’re doing. Motivation is no trivial matter. So in this post, we’ll also discuss a few important parameters that your team can use to judge how motivated they are with the work they’re doing and the way they organise. Consider this as a set of sensible defaults to begin your journey of change.

Let’s look at the categories of collaborative tools most software development teams will need. Many of these will seem familiar to you already, and that’s a good thing. You just need to use the tools effectively. I’ve broken down the list into three categories - must haves, good to haves and optional extras.

In the previous post, we discussed how written communication is the number one superpower when working asynchronously. In this post, I’m adding three more superpowers to the list. Think of these as a quartet of abilities that will help you and your team to supercharge your individual and collective effectiveness.

1. Distraction blocking

2. Reading and comprehension

3. Working independently

There’s no asynchronous work without written communication. It has several benefits over just verbal communication and even over audio and video. This post articulates those benefits and shares some resources you can use to build this remote working superpower.

If as a leader, agile coach or change evangelist keen on introducing asynchronous work practices on your team, you may be daunted by the potential obstacles you may face in the journey.

In this relatively shorter article, I’d like to share with you three 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.

The first port of call for any change journey is your immediate team. If your colleagues don’t commit to change, it’s unlikely that even in a conducive organisational culture, a shift will happen.

As an evangelist, coach, consultant and change maker, anticipating push back from your team will help you deal with it as well. So in this article, I’d like to share with you some blockers you’re likely to encounter from your colleagues and towards the end of this piece, we’ll consider some high-level approaches to address these blockers.

Introducing change in large organisations is tough. Synchronous work has a 250 year old legacy and organisations are used to it for a number of reasons. As an advocate of asynchronous work, you need to be aware of the potential challenges you’ll face when you try to introduce a new way of working in any organisation.

This article outlines some of the obstacles you should expect.

Distributed agile software development projects rely too much on synchronous communication. This not only leaves too little time for deep work, it also leads to burnout, less diverse teams and knowledge and information sharing practices that don’t scale.

Asynchronous work has the potential to transform distributed agile so it’s fun, sustainable, inclusive and scalable.