Asynchronous communications — core symptom of well designed team processes
Imagine it’s the middle of a workday. You’re working on your task, this time it’s a new feature for which you’re in the middle of writing some tests.
Slack notification pops up — it’s QA from your team. They say that there are some bugs in another feature you’re recently delivered.
They write “Can you please take a look?” and sending reproducible examples. “Sure”, you’re replying, having an intent to work on these bugs right after you finish your current feature.
What do you think about this situation? While this may seem like a minor interruption, for me it highlights potential issues in the team’s development process.
What’s wrong?
Assuming we have some basic project management process in place — issue tracker, tickets for user-visible changes, some planning. If so, the fact that team members overwriting these processes by DM-ing each other have the following problems:
- Lack of Publicity: Private communication hampers the team’s ability to understand decisions made, crucial for long-term projects.
- Synchronicity: Unscheduled requests disrupt individual momentum and hinder overall development speed.
- Lack of Transparency: Decisions made on ad-hoc requests might lack justification or evaluation by project managers.
- Lack of Scalability: The informal approach may work for small teams but becomes problematic as the team grows.
Why is it happening?
In my experience, there are 3 main causes, codenames are “Lack of trust”, “It’s easier” and “What’s the difference”. Let’s break them down one by one.
Lack of trust
Team members are overwriting the processes because they don’t trust them. Maybe QA is afraid that the developer will ignore the ticket and is looking for personal commitment. Or the product manager is asking developers to put the issue “higher in the list” because there is no trust that this actually happens if you’ll just set a proper priority in the created ticket.
Consequently, lack of such trust has 2 causes:
- Processes are actually working and people just needed to be convinced that if they use it everything will work
- People are right in their lack of trust and processes are not working
First case is simple — if processes are already good just ask people to use them. Find the prominent examples in the past and showcase them. At the end of the day proper processes make life easier for everyone involved — find an argument for your team and convince them to try.
Things are not that simple if the actual processes need to be improved — in this case it’s a duty of the team to improve it. Find the actual incidents when processes didn’t work, make a retrospective on them, plan and execute the changes so such situations won’t happen again. And after that ask people to try and iterate on newly found issues until the team would genuinely trust the process.
It’s easier
As we already talked, the main goal of processes is to make the life of everyone involved easier. In some cases overhead of the processes doesn’t bring enough benefits — try to find those cases and fix them.
Maybe your issue template has a lot of required fields to fill in. Or maybe a lot of information needed to be filed manually each time. Find the reasons and simplify the process or implement the tooling to make the overhead worth the effort.
What’s the difference?
Somewhat continuation of the previous point — team may not be aware of the benefits the processes may bring. As with other cases it’s, again, either a problem of team perception or the process implementation itself. If the team doesn’t see how these processes will help them — showcase the convincing examples. Or, if it’s not the case, work on finding and improving (or actually dismissing some) the processes.
