Feb 17, 2009 / Organizing Support in Agile Product Development Company

1 comments

In 2007 we released TargetProcess v.2.5 with Help Desk on board. It was a quite powerful help desk with email integration and Help Desk Portal application. It opened new ways to provide support. We merged all support sources into one place: Help Desk. Customers send emails and they are converted to requests, sometimes customers post requests directly via Help Desk Portal. Also we have a support forum, but currently it is disconnected from Help Desk and should be monitored separately. So we had almost all the requests in one place, it looked like a good start.

Unfortunately it did not work as expected. We missed requests, we missed some communication threads and overall support quality was unstable. There were several reasons for that:

• When someone adds a comment to request, we did not receive notification. If a comment was added on Friday's evening there was a good chance to miss it.
• Sometimes we closed request thinking that the problem was resolved, but it was not. Customer would get back with comments and receive no feedback.
• There was no single person in charge of all incoming requests.
• Bugs created from requests live in backlog for quite long (several bugs have been living in the backlog for about 2 years, well, they have Small and Normal severity, but still too long).

Over the last two months we focused on support process improvement. We discovered the roots of our support problems and formalized the support process in just several simple rules.

1. Single Queue Manager. Queue Manager is responsible for all the incoming Issues and Questions. She handles requests Queue. It is a very important job and a good queue handling is a key to the great support.
• There should be no requests with reaction > 24 hrs.
• All simple requests are to be processed first (if the request can be answered right away we just answer it to shorten reaction time).
• Complex issues get prioritized and sended to QA team (QA team decides who will reproduce the issue):
• QA is responsible for the issue and communicates with customer directly.
• A bug is created from the issue and then assigned to Support Release. Support Developer takes bugs from this release and works on them.
• Product Owner is responsible for bugs prioritization in the Support Release.
• Scrum Master is responsible for new builds releases with bug fixes.
• Follow-up. If there's no reaction from customer during 2 days, we should send a follow-up.
• Clearance. Each week all issues and ideas with last comment from our side and no reaction from customer during 7 days are closed by Queue Manager (customer does not want to help and we're unable to reproduce it, so the request is closed).
2. Support Developer. One developer is allocated to support full-time each day (developers rotate during the week).
1. He provides technical help to Queue Manager and resolves complex issues.
2. He fixes bugs created from requests.
3. All ideas are handled by Product Owner.

This process has been working over the last month and I should say it works fine. Reaction times improved significantly and no requests are missed. Maybe this simple process will help other product development companies. In fact there is quite a few articles and discussions around support organization. Hope this one will be helpful and you will make less mistakes than we did.

One thing to add. Requests Queue Manager is a highly responsible job. This position demand extraordinary responsibility and the person should REALLY CARE about customers. That is the key.

Labels: help desk, support

posted by Michael Dubakov @ 6:57 AM

May 10, 2007 / Why Project Management Tool Demands Integrated Help Desk?

0 comments

Interesting question. No, we don’t want to create bloatware with thousands features, complex UI and 100MB installation package. We have clear goal – help agile teams to complete projects in the most efficient way. In fact I think Help Desk/Customers Area is one of the most important modules, it helps to manage customers feedback. And customers’ feedback is the MOST useful thing you can get to improve your product, to make it really useful.

So it is all about Feedback Loop in software development. Help Desk module will provide the complete feedback loop. Check the picture below. In fact it is very clear and simple picture of any software development business (replace Help Desk Module with requests stack for example).

1. You get feedback from customers (end users if you do product development).
2. You handle the feedback somehow (Excel, cards, custom database application, office walls and floor, product manager’s long-term memory).
3. You create features and bugs based on provided feedback and own vision.
4. You implement features and bugs and deliver software to customers (expecting that they will be happier and they satisfaction will increase).

That is how almost any software development process works. Almost all Project management tools focus on Implementation (TargetProcess as well till TP 2.5 release). The tools do not care how requirements put in, the tools just manage defined requirements (user stories, epics, features). There are several problems with that approach:

1. You should manage initial requests and ideas outside PM tool. This complicates things. You need integration and this will take additional effort and time and likely end result will be not the best you can get.
2. Relations between initial request and resulted features often lost in space. You don’t remember who requested what, how many customers requested the same feature (and this information is very substantial, likely the request is important).
3. Customers can’t check progress. All they may see is that “request XYZ accepted”. In the best case you may spend a lot of time and drop them emails with confirmation that request accepted and planned for release #12.8.

What is the conclusion? The conclusion is that you may do way better with integrated Help Desk on board. Many, many things will be automated. You will not spend hours writing emails and do status reporting. You will always have clear relations between initial request and final implementation. Support will be simplified and customers’ attitude will be improved. You will receive more testimonials with “excellent support!” words and you will have more new customers.

There are no reasons to not include Help Desk into TargetProcess. The only reason is more complex UI, but TargetProcess has Process/Practices concept and it will be possible to turn off Help Desk practice and stick with simple UI if you don’t need Help Desk. We use TargetProcess for TargetProcess development. We NEED that module ourselves! We receive 20-50 requests each day. We spent a lot of time on these requests and still we don’t have clear process in place. We’ll benefit from Help Desk and it means other companies will benefit as well (we’ve already have many requests for that module to be honest :)

Next release of TargetProcess will include Help Desk. It will close the loop between development team and customers (however if you don’t have good interaction with customers then TargetProcess will not help, it just saves time and automate several things).

Labels: help desk, project management, support

posted by Michael Dubakov @ 3:00 AM