In a software development company that works for external customers it is common to spend significant amount of time dealing with external issue reports. While being tedious, this activity still conceals great potential for the development team's efficiency improvement and professional growth. At the same time this process is frequently organized in such a way that it never allows to get these benefits. In particular, that was the case in our team not so long ago, but we were able to change this for good.
Developing the ERP product we do face lots of support requests from our customers, some of which get escalated to development and turn into bug reports or new functionality proposals. Originally, there was a single person responsible for monitoring the queue of such items in each development team - the team leader. He would constantly keep an eye on the list of new bugs, analyze them one by one, which sometimes means debugging, comment them to provide first clues to the reporters and ensure that they are handled in a timely manner.
This approach has apparent problems, the most obvious of which is the lack of resilience. When the team leader is suddenly out of office, it is difficult for the team to take charge of the incoming requests because no one is used to the process. And even when the lead's absence is planned certain effort is required to ensure that someone on the team knows what to do about the queue and understands his responsibility for that - again, because the team members are not familair with the activity. This approach also puts significant load on the team leader and reduces his availability for other tasks - both organizational and development - which is rarely what we want. At the same time, when he actually has to do other job, fresh high-priority issues may be assigned to other developers and disrupt their plans in a chaotic manner.
To get the idea of a better organization of this process it is worthwhile to examine the things that constitute it. Handling of any external request always starts with analysis of its validity, asking for additional information from the reporter, search for similar requests in the issue tracker or forwarding the problem to another team responsible for it. Subsequent analysis may require debugging and playing with the application and is usually aimed at both tracing down the root of the problem and providing a workaround or hotfix if it is required. In some cases one may produce the actual fix for the problem in the code - usually that happens either when the fix is simple or if the issue is very urgent (bad motivation, but that's another story). Frequently, though, the process ends with consolidating all the obtained information in the issue report and dispatching it to the most appropriate developer to be fixed sooner or later. The common feature of all of the above tasks - except possibly choosing the right assignee and implementing the actual fix - is that they can be done by any developer. Combined with the problems outlined above this idea brings us to a reasonable alternative implementation.
Instead of forcing all the activities associated with analysis and distribution of the new issue reports on one person it is way more efficient to evenly distribute this activity between all the available developers. The easiest way to organize this is to have them take turns so that each week one developer is fully responsible for managing the queue and has very few or no other tasks - in our team we call it Watch. While this process does require some degree of organization, it is not very difficult to put together. One has to carefully maintain the sequence of watchers and ensure that each team-member knows when it's time for him or her to go on duty. It is also crucial - especially at the beginning - to produce a piece of internal documentation explaining what processing a new issue report means and conveying the objectives of the process clearly. Major goal here is to encourage communication between the person who handles the requests and all the other team-members, such as product managers, other developers and support - it is vitally important for proper analysis of issues and for making the right choice of the way to handle them. Finally, to make sure that everyone who goes on Watch is efficient at it, someone should monitor quality of the results - this can be done by means of a regular review of several random closed cases with each developer or through any similar process.
While, unlike the original approach where one person is fully and permanently responsible for the job of handling incoming requests, the Watch process requires a bit more effort to establish and maintain, its enormous benefits to the entire team fully justify the cost. Most obviously, it enables better load balancing and - through explicitly securing one developer for unplanned activities - better planning. In addition to that it makes the team more resilient improving distribution of knowledge on different aspects of the product between team-members. This is especially helpful when there is a degree of specialization in the team. Importantly for support and customers, such organization also decreases the time required to respond on a ticket, because the developer in charge of the queue is not loaded with other tasks and focuses solely on making the issue reporters happier. The fact that the process encourages collaboration and forces regular changes of the work mode - between development and support-like activities - contributes even more to the overall efficiency. Finally, when developers face a load of raw external bug reports from time to time, they become more aware of customers' needs and position and thus more motivated to do a better job.
As usual, these benefits don't come at no cost and there are some problems that one may face while establishing Watch in a development team. In particular, developers accept this activity differently and some may really hate it - especially in the beginning - which may require additional management work and certain adjustments. The way people handle the bug reports also may differ. For example, some initially focus on fixing items instead of doing faster pre-processing to provide quick response to the customer and adequate information to the person who can address the issue better. Or it may happen the other way around and you may face a situation when very little analysis is performed before stacking a request into the backlog. What may be most scary, almost inevitably performance of the team will drop after the process is introduced - each week one developer will devotes all of his or her time to an unfamiliar activity instead of actual development, but this is a short term effect and it diminishes quite quickly.
We faced some of these issues when we introduced this process in our team, but despite this the change looks totally positive. The fact that I, as a team leader, got partially freed of this activity and now have more time for other business obviously makes me happy, but its effect on our cumulative efficiency is way more important. In particular, the process boosted developers' expertise and domain knowledge growth significantly. I also saw it work great during my recent vacation without any extra effort on my side - last year it was different. However, what surprised me most about this organizational change is that, while originally I expected a strong pushback it was accepted positively by the teammates. So it is almost a year since we began our Watch and I'm absolutely sure that I would never go back to the old way of handling incoming issues.
