Feb 24, 2009 / Friday's Digest #9 [Pair Programming, Design, CI]

0 comments

• I Love Pair-Programming. Fantastic real-life experience of pair programming. It is hard to advertise it more.
• 21 ways to hate pair programming. Nice list of mistakes people often make when doing pair programming.
• Fantastic sign up form. Creative way to provide sign up form. Not sure about usability (on my opinion not much difference from usual form), but it is eye-catching and "tangible".
• Continuous Deployment is about deploying code changes to production as rapidly as possible. "Every commit should be instantly deployed to production". Is it possible? IMVU proved it is. Nice goal we should strive for. Extreme case of Continuous Integration is Continuous Deployment.

Labels: digest

posted by Michael Dubakov @ 6:28 AM

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

Feb 6, 2009 / Friday's Digest #8 [Scrum, Lean, Economy]

0 comments

• Martin Fowler emphasizes that technical practices are very important in Scrum process and team can’t succeed without them. The same thing is true for Lean.
• If you don’t know how pull systems work, here is a good article that describes that in details. Moreover, it shows how to create various pull systems from a single workflow by applying various limits.
• "Do You Austrians Have a Better Idea?" Creative recommendations for President Obama. Recommendation #5 - "Eliminate the DEA and the SEC. Since the SEC failed to catch Madoff, despite nine years of warnings, I think its $950 million annual budget is obviously a waste of money."

Labels: digest

posted by Michael Dubakov @ 10:26 AM

Feb 4, 2009 / Support in Agile Product Development Company: Email Client

2 comments

We are working hard to improve our support. Sometimes it is very good, sometimes not. We are receiving about 20-40 requests each day via emails and Help Desk Portal, also we have several chats and phone calls. I want to share our experience and problems we are facing with, maybe it will help other companies to provide good support faster.

Manage Support using Email Client

Initially, as may other companies, we just use email client to handle incoming issues and requests. It worked fine for 2 years. There was a single inbox for all support requests and there was a single person who handled it. You may flag important requests and track them. For example, if important issue submitted, you may ask for additional info, submit a bug into TargetProcess and notify customer about new build when the bug is fixed. Usual questions are even simpler, you just answer them and forget till customer asks for more info.

However, support management via email client has several important problems and constraints.

1. It is really hard to track many requests with it. The good thing is that you have requests queue and may handle new requests nicely, but what about old requests that are not resolved so far? For example, bug created from request and it is still not fixed due to various reasons. Also we may ask for some additional information, but customer did not replied. It is likely that we want to re-ask again, but it is quite easy to forget that.

2. The other problem is when you have several people working on requests. It is not clear what request already answered and what request still waiting for the answer. 37signals uses gmail client for that and it seems it works fine for them. However it is not true for usual email clients like outlook.

3. Third, if you have several channels (live chat, phone, email) it is hard to manage them. For example, you have discussed the problem in the live chat and now want to create a bug. You add a bug, but forget to notify customer about new build when it is ready, since there is no such email in support inbox at all.

As you see, email client does not scale. It can be used if you have low volume of requests, but at some point you need something more efficient.

Labels: support

posted by Michael Dubakov @ 4:56 AM