We were three months into our Beta period, our issue tracker was piling up with feature requests, todo items, bug reports, and we were just two people!
We did our daily standups, we made sure to verbally sync on issues, we followed good triaging protocol to assign tasks to the person who could best solve them, but issues were still falling through the cracks.
Despite assigning issues, we weren’t sure they were being addressed. With a small change to our process, we overcame this confusion…
Determined to not let this get the best of us, we put our heads together, and nearly overnight we eliminated the confusion we had before.
The solution, in our case, was to incorporate acknowledgement into our process. Read on to see how we built this principle in our process…
The current methods weren’t enough for us
Before discovering this principle, we looked to see how other groups keep their own teams “in sync” and tried them out.
The Trello team suggests that keeping your issue tracker up to date avoids “information asymmetry” among members, but this wasn’t enough for us. We tried augmenting this with daily “virtual” standup meetings that included (1) a one minute summary of what we did, and (2) what we’re blocking on.
We experimented with iDoneThis, which provides an alternative way to do this asynchronously via their email-based system, but found face-to-face updates more natural in our two-man team.
Zappier’s suggestion to post all of our updates on Slack and doing a video call once a week to map out what we’ll do was helpful as well, but one week between calls was sometimes too long for us.
Buffer, who themselves face the challenge of coordinating teams from China, to the US, to Europe, advise “daily pair calls” with different pairs every week so that people across time zones stay in sync, but being just the two of us, it didn’t quite apply.
While the above are good alternatives that worked for their respective teams, for us, the solution was more subtle. We found that incorporating acknowledgement into both our issue tracker and our use of Slack was the key change that resolved our confusion.
Here's how we specifically did that:
1. Use the “New” status in your issue tracker to mean “Unread”.
When an issue is assigned to another person, we set it as “New”. Once the other person sees the issue, they change its status to “Confirmed” to acknowledge that they’ve seen it, or as “To be discussed” if they need additional information.
As part of our daily routine, we regularly check if there are any remaining issues that have their status set as "New". The simple ethic has saved us heaps of trouble in needing to follow up on issues and ask about their status. We no longer have to wonder if the other person has seen it, since there is, at a minimum, an explicit acknowledgement of the issue.
The people at Groove have a similar method, although they call it an “Icebox”. In their version, they don’t allow any issue to remain in the icebox for longer than a day, and they assign a person to be the “gate keeper” that is in charge of clearing the icebox. In our case, we are responsible for clearing out our own issues within a day of being filed in the issue tracker. We both check the “New” column daily, and there’s peer pressure to acknowledge an issue.
We found this to be a key aspect in the process: the person reporting the issue is relieved of the task of checking if the other person has seen it, which made filing bugs a "fire and forget" type of action. We are now confident that no issue with status "New" stays that way for longer than a day, so once we've filed it, we can go on with our lives.
2. Use Slack “reactions” to acknowledge comments.
We share a lot of resources and guides with each other on Slack but, much like it happened with issues, we weren't sure if the other person had seen them. Our solution to this is simple: use Slack reactions!
For every article that we find interesting, we add a reaction to it. That means that for every “10 ways to improve your unit tests” article, we diligently add a thumbs up emoji to communicate that we read it, and, when possible, write our own response to it. This lightweight ethic allowed each of us to scroll through our Slack history and easily spot what we missed. No more "Article... what article?" from either of us.
3. Talk to people immediately for urgent issues.
If an issue is extremely urgent, don’t wait! After creating an issue, we reach out to each other directly on Slack or push-to-talk. The other may be busy, but contacting them reinforces the urgency of the issue, and we ended up getting more consistent results this way.
We strive to keep this at a minimum, but sometimes fires need to be put out.
In the world of powerful asynchronous tools like Slack, Trello, Jira, Redmine etc., you can assign and send information to your teammates, but unless you have some feedback, it may feel like you’re sending an issue into a black hole. In fact, visual feedback was a key element for us in synchronous meetings. The solution, then, was for us to provide each other feedback by building acknowledge into our process, for both our issue tracker and Slack.
You can incorporate acknowledgement into any process (tools like Calendar invites, for example, depend on this). Since we work remotely, we’ve had to take an extra step and manually enforce it, but for us, it’s paid off in spades.