This post is the first in a series explaining the challenges we face in managing work requests, bug tracking and other operational processes. Specifically, I'll cover Jira, the tool that we selected to help with these challenges, as well as the ways we've configured it to suit our culture and needs.
Part of my job is figuring out how we can work more effectively, and one of the first areas we needed to tackle was our work request system. Our overarching goal when managing work requests is to allow Digital Media to easily separate the noise from the important stuff. You know that scene right after the crash in the first episode of Lost where Locke sees the equivalent of a redshirt wandering near an intermittently-spinning jet turbine, and the guy can't hear the specifics of Locke's yelled warning so he stops long enough to shout "What?!" and then fahWHOMP— redshirt becomes strawberry jam and the engine explodes and a horrible situation just got worse? Here's a refresher:
We needed to stay off the path to experiencing our own redshirt schmear in the midst of premature labor, ineffective CPR, and lethal chunks of flaming metal shrapnel. Maybe ours wouldn't be as messy, but certainly no reprise of Beach Blanket Bingo.
Our ops demons and how we started taming them, after the jump.
We face the same operational challenges as most small-to-mid-size development shops when prioritizing:
multiple types of requesters with different levels of expertise
Our requests come from a wide range of people, including senior managers, interns, contractors, developers, project managers, and designers. Each stakeholder has a different comfort level with and ability to describe technical problems and suggestions for improvement. Our process management system must accommodate all of our users, making it as easy as possible for them to log and track issues.
multiple paths for making requests
Folks stop by our desks, call us, email us, IM us, report bugs in tracking systems, and pass along problems while walking by the kitchen when we're nuking lunch. We don't want to limit the amount of human contact, but we do need a central repository that we encourage people to use.
multiple types of requests
We get everything from backend changes requiring a release to design reviews, documentation needs, and front-end changes. Often, the requestor doesn't understand the scope of what they're asking for or how it might impact other applications or users. We need a way of bucketing the same types of requests and providing an LOE estimate.
different teams working at different levels at the same time
On any given day, we have a mix of 40+ developers, information architects, project managers, designers, and product owners working on projects, production requests, and emergency and planned releases. They need to be able to filter by and switch from type to type with a minimum of effort, and they need to see what everyone else is working on.
figuring out resource load
We receive hundreds of requests a week and have a limited number of staff and contractors who can address them. Our work request system should ideally show us how much work each developer or designer has in his/her queue and allow us to adjust the load for peaks and lulls (not that we've seen much of the latter).
Taking these key challenges into account, we established some process ground rules, which include:
1. Jira isn't meant to take the place of human interaction. We use Jira to document, plan, track, and report on work requests and bugs. It's not like that fishing game at the community carnival where you cast your line over the wall and reel in your random prize when you feel a tug. We want our reporters to know exactly what they're getting, and we depend on them and many others to help us clarify and work collaboratively.
2. Jira isn't the first point of contact in a true emergency. While it doesn't take much time to enter an issue and several folks are monitoring Jira throughout the workday, we don't have 24/7 coverage and we don't have any staff 100% dedicated to triaging Jira tickets as they come in. If our site is down or an editor on a breaking news deadline can't publish, folks call an emergency support number, come to our desks, or page us on the intercom. Only if necessary (sometimes after the fact) do we or they enter a Jira ticket.
3. Product owners decide the priority of the issue. In the past, many requests requiring business analysis came to the developers for resolution. We tried to pull in product owners whenever possible, but it's a conflict of interest for developers to be setting product vision for stuff we don't own. Our new process makes product owners the first assignee by default.
4. Only one person is responsible for a Jira issue. This rule addresses the challenges we have when someone sends a request to an email distribution list: multiple email threads start, it may not be clear who is working on it (or if anyone is working on it), and a lot of time could pass before it's resolved. The assignee is the person who has to do something with the issue — even if it's as simple as assigning it to the right person to carry out the work. Other group members may be notified/watching, but only one person owns an issue at any given point. Throughout the lifecycle of an issue, product owners need to weigh in, but they generally don't execute the work for task.
5. Closed issues stay closed. We often reopened bugs weeks or even months after they were closed, either to flag a recurrence of the same problem or to add comments about a new, related problem. Now, production code changes are tied to specific Jira requests, which enables more efficient troubleshooting and insight for future development. If a request goes live after UAT (User Acceptance Testing) and there's a production issue, it's a different problem and a new request is opened. We sometimes link to related issues to clarify the new problem.
6. We're never done improving. We're treating the work request process like our bastardized Agile development process: we learn more as we use it and make adjustments as necessary. Since we launched, product owners received more Jira permissions in order to ease a triage bottleneck. We're working on determining our optimum velocity for planned releases. We still need to come up with an overall plan for prioritizing production requests, now that Jira has been open to all Digital Media users for a little over a month. We know we always can do better and try to be as flexible as possible.
So, why did we end up choosing Jira? Find out in my next post, "You say Godzilla, I say Gojira."
* I wish could take credit for the title of this post; Harold Neal (Senior Software Developer) said it while reviewing the Jira implementation plan.