đź“Š Building Triage
I found that communicating development progress across internal teams and externally to users, in way that is understandable for all and manages their expectations, can be tough.
The Problem
In the company I had recently joined, I observed that individual teams were great at their own processes that helped them to keep track of their projects and tasks, measure performance and deliver; but things weren’t so great when it involved working with other teams. I realised this was because there were no processes here for teams to work together.
The biggest impact that this problem had was on our day-to-day development in the product team. Users would send the support team (via Zendesk, email or phone) either feature requests, questions about the product or bug reports; the support team would then log those and pass feature requests and bug reports on to the product team. Once those were passed from support to product — the only communication from one [team] to the other was through Google Hangouts conversations which meant that information could be lost, not communicated in a timely manner or only known by one or a few individuals; which often left people in the dark.
The Idea
I made it my mission to tackle this by building a process and tool that would bridge together the two teams. More specifically, the process would: be the source of truth for the up-to-date status of development work for customers and bug reports, report the status in a format that the support team can understand.
The prototype I had built (and named “Triage”) was a Google Sheets document that would hold the list of all customer requests, with the type of request, latest status, the ticket number of the customer request in Zendesk (our support ticketing system) and the ticket number of the development work in Assembla (our issue tracker).
The magic that allowed this to work was with Google Apps Script. The script would accept requests from Assembla, so that when developers had made progress, the script would update the spreadsheet.
Our Assembla setup had a lot of statuses that only mean something to the development team (such as the code review stage). So Triage had to have its own set of statuses that was digestible for the support team.
Triage would also keep a log of when statuses changed, so that teams can get an idea of how quickly a feature request or bug report gets from being reported, right the way through to being delivered.
As I mentioned before, Triage exists to be the source of truth for the up-to-date status of development work for customers and bug reports; and report the status in a format that the support team can understand. Now that I’ve deployed Triage and the teams will start using it — I’ll observe how the teams’ communication of development work changes.
