Go async-first with your team
Use the filters below to find async-first methods that are relevant to your team. For detailed articles, check out the blog.
Write once, run many
Switch from fragile, redundant, ephemeral conversations to shared, persistent onboarding assets.
Pull requests
Pull requests are a feature that most source control systems provide (GitLab calls it a “merge request (MR)”). This feature allows anyone who wants to contribute code to a project, to package their changes so someone else can review their code before merging it into the codebase.
Business decision records (BDRs)
By documenting every business decision you make for your project, you help your present and future colleagues understand the rationale of why things are a certain way for your team.
Commit messages
Effective commit messages are a way for developers to communicate to each other about the changes they’re making to a codebase. These messages can be useful when fixing issues or when finding the root cause of a bug or even when troubleshooting a broken build.
Architectural decision records (ADRs)
Your architecture will change with time and in the future you may have to investigate why your architecture is a certain way. Architectural decision records (ADRs) help by providing an archaeology of your project.
Meeting minutes
By going async, you’ll limit the number of meetings you have. For the meetings you keep, you must afford your teammates, present and future, the courtesy of a meeting summary; a.k.a meeting minutes.
Demos only when necessary
Let’s be honest. Teams don’t always have something big to showcase every sprint. Without substantive demos, the sprint reviews become a formality and a reporting exercise. Take a pragmatic approach to sprint reviews instead.
Avoid communication blasts
A single line message that you send to 200 people isn’t a single line message anymore. It’s a 200-line message. Instead, “shrink the blast radius”.
Target your conversations
Limit chat conversations only to those necessary to the discussion.
Form based estimation
Back in the day when agile still wasn’t a thing, wideband Delphi estimation involved anonymously filling out forms. You can do the same thing now, but more efficiently with online forms.
Async velocity game
You don’t always need a long meeting to play the velocity game. It’s easy to run this using a simple survey.
Large effort estimation
Nigel Thurlow and Dave Slayton came up with this approach to estimate scope, at Toyota. You can use this to estimate size at the start of a project. You can also use this technique when you have to estimate a large amount of scope for an in-flight project.
Warp speed estimation
Warp speed estimation is a way to quantify scope at the start of a project.
Create autonomous pods
Create smaller decentralised pods inside the team to devolve responsibilities. Pods operate autonomously and make their own decisions.
Revisit your workflow statuses and transitions
Most project management tools allow you to define a workflow for your team and visualise that workflow as a task board. When you revisit your workflow be careful not to design for the exceptions and worst-case scenarios.
Make the task-board the central communication tool
Most project management tools allow you to define a workflow for your team and visualise that workflow as a task board. Your task board should be the source of truth for all the work your team is up to.
Write a team API
Broadcast how your team will interact with other teams, using a TEAM API.
“Go DEEP” with artefacts
Distributed projects are chaotic to run without artefacts. The DEEP acronym provides you a mnemonic to remember what to document.
A WUCA approach to complexity
Complex topics need time to understand and to engage with. WUCA outlines a team approach to deal with complex discussions.