How to facilitate an async work culture
Whenever I leave a team retro that revealed our dissatisfaction with our last sprint I tend to observe the same pattern.
Usually, we complain about having too many meetings and suffered from a greater number of ad hoc dependencies. We worry about severe wait times, task hopping and overall stress on the development side.
However, not only the development suffers under these conditions. This pattern is likely to be accompanied by the fact that the product decisions made under time pressure are more prone to failure. Primarily because discussions are not facilitated with a broader audience and discussed with the team.
And most of the time we identify one single cause: Not enough planning was invested - not enough documentation has been prepared.
I believe that this analysis is correct, but does not comprehensively recognise the underlying problem. There is an even higher goal to strive for. I think the solution to the challenge is to focus on developing a better asynchronous work culture. Let's take a look at what it takes to build a delighted and efficient remote team.
Why asynchronous is better
Async in itself has no value, it is rather a vehicle or tool to achieve a happier and more efficient working environment. GitLab - as a remote-first company - identified a few distinct advantages of async work. Two of which I find particularly worth citing:
- For the team members, it provides autonomy and empowerment as they can plan their work around the rest of their daily life. It doesn't matter if a task is carried out late at night or as a nine-to-five job. It doesn't matter when the work is done, only that the result meets the team's expectations. I for my part love spending the afternoon with the family and enjoy the fact that I am free to work in the evening for a few extra hours.
- Async furthermore reduces stress and supports your mental health as you can work without being bound to strong deadlines and the urgency of replying to every message within minutes.
A well-planned sprint is the single most important foundation for such a working model. This reality makes a successful async work culture very dependent on the product owner as he is usually responsible for planning a sprint and maintaining a backlog. My adventures as one have taught me three lessons I would like to share:
Documentation is key
You can't do async communication without strong documentation. That not only means technical docs but especially any communication around a feature that is about to be developed. In the PO case, the most prominent cases of documentation are backlog items and user stories. We are anyway at risk to overload an issue with user stories, acceptance criteria, technical notes, to-do lists, technical Information, design notes, etc. It can quickly become overwhelming when you try to take strong documentation seriously.
However, strong does not mean that your docs need a lot of words. From my experience even with little text and the right system, we can document the significant aspects sufficiently. My team and I limit our backlog items to a set of three "must haves" to fulfil the definition of ready. Only in a very rare number of cases do we feel the need to extend it - and if so we just do.
- User story (of course)
- Context
- Szenario(s) (as acceptance criteria)
- Design (optional)
We hereby follow a quite traditional user story template. However, we reduced it to the raw core.
One crucial part we have in fact added is called context which describes the story behind the story. Through the introduction of a contextual section, which may even be more detailed at times we document clearly why something has to be done, what stakeholders are in need of it and/or how it adds to our overall product vision. It invites team members to reflect on the proposed solution once more and empowers them to solve smaller complications autonomously while implementing it.
The second essential part has to be the scenarios. From my experience, these scenarios can be expressed best when following a system. Not only do you become extremely fast at describing your features using the same system each time, but your teammates also become accustomed to it so they can grasp features faster. We are solely using Cucumber Scenarios that likewise act as acceptance criteria for a story. They are easy to write and even easier to scan and revise during planning. I really enjoy writing them because I almost every time find more edge cases to deal with.
In rare cases, I extend the scenarios with a state machine model of how I picture the system to work. As you can see in my other posts, I am quite a fan of xstate and I really appreciate working with their web editor. For example, I have modelled the states of a discount code field and made its behaviour transparent. Next to the written scenarios, such a state machine can make a feature playful to experience.
Unfortunately, one problem remains: No matter how much you write down, it will be too short - and that's OK. Many tasks concerning the product are so extensive and have so many edge cases that it is difficult to cover them all beforehand. But you should at least try.
If we took this achievable DoR seriously, we frequently found ourselves in very asynchronous sprints. Whenever we didn't take this into account and started a sprint too hastily, at the latest two weeks later we regretted doing so.
A story following this approach could look like that:
It's okay to be the parrot
Don't be afraid to repeat things - especially the broader product vision! Sometimes I feel strange repeating things 3 or 4 times, to explain them again, to describe the background one more time. I may sometimes explain an idea during planning, write it down in the ticket, then tell it again on a daily, and still, you may end up being misunderstood. But the more often you elaborate and thereby do variations of the same explanation, the more certain you can be that you have been understood in exactly the intended way. Knowledge does not spread like wildfire. You have to feed it oxygen to keep it alive.
Make meetings about decisions
...and document them!
We all know the phrase "This meeting could have been an email" and there is so much truth to it. Sometimes meetings are inevitable. As they are a fixed block in everyone's calendar, every (team) meeting you set up is by definition not asynchronous and therefore needs a strong reason to exist. You are not only blocking someone's time, but you also limit someone's freedom to structure their day. In our team, we only have two fixed meetings you are invited to join - one is our daily and the other one is our retro and planning block every two weeks. If you can not make it to one of these meetings we follow a "don't ask, must tell" rule.
We have not yet introduced a mandatory written agenda for meetings - even though I think it would be a good idea. At least for my part, I try to start a meeting by verbalizing the decision that needs to be made and presenting a preliminary strategy to get to it. After a meeting, all team members who were not in the meeting are informed of the outcome. For us, this is just a short slack message in a team's channel. It doesn't sound like a big deal but it helps tremendously to keep everyone informed and on track. I admit it could be more detailed from time to time.
Don't get me wrong, meeting other people is important for team building, social binding and having fun at work. But from my experience, it is wise to take some dedicated time for the team and fun activities instead of trying to have some quality time at the beginning or end of a decision-focused meeting.
Where to go from here?
This is how we currently strive for more async work and what I as a product owner do to ensure that my team has a strong foundation for that. All of the above is my personal experience and can vary in your specific case. Please feel free to adapt, expand, change and tweak it. We are far from optimal and we are also constantly trying out new variations and modifications in our workflows.
There are a lot of excellent resources available on this topic. I will list some of my favourites below:
➔ GitLab remote playbook