How our team adopted asynchronous collaboration

Editor’s note

Priya Darshini and her team, had always practiced software development, in a colocated fashion. When they moved to a remote way of working, their tried and trusted collaboration patterns needed an async-first twist. This article chronicles her team’s journey of tiny steps to be more async.

My colleagues and I first learned to practice agile software development, while being colocated. When we were in person we had several impromptu discussions and huddles to collaborate. The pandemic and lockdown changed this situation suddenly and our team had to figure out how we can maintain the same level of engagement, while working remotely. 

As you can imagine, the office-in-the-cloud pattern is ineffective for remote work. Face to face discussions become zoom meetings. You end up scheduling every interaction. Before we knew it, our team  started experiencing  Zoom fatigue. Meetings felt like a chore. 

Here’s what we observed.

1. Code pairing sessions began to drain developers’ energy. Staying on call all day wasn't sustainable.  We tried reducing the overlap, but that didn’t help either. We neither got the benefit of pairing nor did we get much focus time.

2. Regular, office centric versions of  agile ceremonies took too long on zoom.  We found them a drain on our  time.

3. There was no difference between casual catch-ups and other  calls, since everything was a Zoom meeting.

So in 2022, when we set up a new team and once we went through the norming stage, we decided we’ll adopt asynchronous ways of working.

The journey

As a part of our preparation, the team referred to various blogs and articles related to asynchronous collaboration and asynchronous variations of agile practices. The idea was to build a common understanding about the way we were planning to work.

In July 2022, we decided to pilot async practices for two sprints.  Through the exercise of fine-tuning our approach, our team learned a fair bit. More on that later. First, let me tell you about some of the practices we adopted.

How we work

There’s no remote or async work, without tools. There are a few key ones we use. 

• Wiki for documentation of context - Confluence

• Chat platform  - Teams

• Task board for delivery/project management - Jira

Details on chat get lost over time. So, if we share any updates over chat, we link it to the central repository. To keep our conversations focussed, we’ve created multiple channels on Teams, each dedicated to a specific purpose.

• General - for generic information

• Design - for XD updates

• Discovery - to share information about discoveries, user sessions, roadmaps

• Story updates - to share details about story status. This is a layer atop regular JIRA updates, so people can see the status of work-in-progress, in a single view.

• EOD updates - to share end-of-day handovers or for topic that colleagues in another timezone needed to follow-up 

We also adapted our sprint ceremonies to be more async. Here’s how.

• Iteration planning. All of us plan leaves using a centralized planner. We determine team capacity for the sprint (and otherwise) using this planner. Story grooming and kickoffs. Our JIRA cards are the single source of truth for the tasks they represent. We update all functional and technical analysis inside them. In case we have questions beyond what the card says, developers, business analysts and testers meet on an ad-hoc call.

• Desk checks/story signoffs.  Instead of a meeting for every story, we deploy all changes to the test environment. These are available for the entire team to verify - not just the tester. Once the testers are satisfied that the changes are good to go, they move the story card to the QA stage. 

• Sprint retrospectives are part async. The team shares their inputs on a Mural board, asynchronously, 2-3 days ahead of time. They then meet for a shorter time (around 30 minutes), for a more focussed discussion and an action plan.

In addition to this, we also did team bonding activities partly async and also using video, on Zoom. This helped our breaks from work look different from work itself!. 

Here’s an example of how we’ve used chat to get to know each other better. We start a thread about a topic that is both fun and personal. It could be about book/movie/TV show recommendations or about sharing pictures of festivals or our even all-time favorite topic, food 🥘.

The impact of the shift

We’ve now been working  this  way for about seven months. Here are some of the positive impacts we’ve experienced.

1. Our team in India, is now far more independent when owning our software delivery process.

2. Documentation discipline related to things like our  product, practices, decisions have created longer term, referenceable knowledge..

3. Since we iterate documents over time the quality of knowledge is getting better with time as well

4. Our communication has become more inclusive. Content is available to anyone when they need it vs only during meetings.

5. We have more personal autonomy. We work flexibly during hours that make sense for us all.

What we’ve observed and learned

While we’re continuing to fine tune our approach, it’s a good time to share what we’ve learned so far. Being async is all about a higher discipline around communication within the team. Here’s something I’d suggest if you wish to go async.

1. Be explicit in your communication and clarify all assumptions.

2. Consistency is key. Be regular with your updates. Err on the side of over communicating if you aren’t sure how much to communicate.

3. Collective ownership extends to documentation as well. Maintain and update documentation regularly so it’s a credible source of truth.

I suggest not to think of async practices as a time saving mechanism. Instead, think of it as a way  to allow your team to focus on the important parts of  your work. For example, repetitive verbal communication can take away focus from delivery. In contrast, you can leverage effective documentation repeatedly. This doesn’t just give you back your focus, you can reuse effective documentation  in different contexts such as delivery, design or onboarding. 

And a word of caution. Written communication needs trust. When we brought new members onto the team, we saw a significant dip in async communication. Guess what, people don’t like writing things up in environments where they don’t experience safety and trust. Recognise trust as a key component of working together. Amongst other approaches, we’ve built trust through informal conversations. 

---

Our current state and how you can go async!

Our team continues to leverage all the benefits of being async-first and we’re quite satisfied with the way of working. If it’s any validation of our success, I must add that when we onboarded client developers to the team, we also introduced them to async work. They too experience and appreciate its benefits.

The internet has many resources for you to learn how to go async. This website is one of them. Check out the best practices section to get started. And if you’d like to contact me, drop a comment on this post or find me on LinkedIn.