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.