Handling Support in Agile Teams
As Developer Testing is become mainstream and teams are looking for pragmatic solutions, we are seeing more and more Customers using TypeMock.
Support has always been a top priority here in TypeMock, our mission is to help developers write unit tests, so if they are stuck -we want to help. This has lead to some problems when planning our iterations.
Here are the reasons.
- We don’t know how long we need to spend on support issues. This depends on the number of support issues submitted and their difficulty
- We need to answer the issues in a timely manner
- Support is an interaction task and requires a conversation with the customer, so sometimes issues are waiting for feedback.
- Our customers are developers, and require developers to answer them (for technical issues)
We have thought of a few ways and tried a few.
- Having a dedicated support group.
We haven’t tried this, but a dedicated support group would mean that the support developers will burnout quickly and knowledge transfer could be a problem. We would loses the group responsibility that is a major value in agile teams. When a developer has to deal with the bug he creates directly from the customer, it changes the whole perspective of code quality - Create an iteration and when a support issue arrives - it gets top priority.
This way we get to do the high priority work in any case. This didn’t work very well, there is too much context switching that drives the team crazy. We have seen that this method creates a large risk that the whole iteration in spent in support - Spend the first week of the iteration doing support.
This doesn’t work well as issues that come after this week must wait a few weeks until being looked at and that high priority issues will in any case take preference over development and causes the iteration to grind to a halt. - Have the developers take turns in being dedicated to support, example, have each developer pre-allocated for support one week per month. This gives a good way to measure the amount of support and allows other developers to develop the tasks of the iteration. We are still fine tuning the way that issues get handles from one developer to the next, but it seems to be a good way.
Do you use any other way?
Bookmark at:
Subscribe!
RSS 2.0
4 Responses to “Handling Support in Agile Teams”
1 Ngu Soon Hui 12 December 2007 @ 4:54 am
Good post, but I have following questions:
# More often than not, the developers have their different domains of expertise. What if I receive an issue which I am not familiar with when I am wearing the technical support hat? Should I get to the developers in charge or I try to solve the problem myself? I may not be able to solve the problem even if I want to. Or if I pass the issue to the developers in charge, then it becomes his problem. This, seems to me, is defeating the purpose of rotating the technical support. The very point of rotating the technical support hat is to let only one person worry about answering customer’s call and let the rest focus on development tasks.
# What if an issue requires a long time to solve? Then multiple developers may be involved, and there is a waste of the developer’s time because each of them need to update themselves with the latest development. But if you have a dedicated person to follow through a problem, then you do not have to spend time passing the cases around and updating everyone involved all the time.
# Developers like coding, disdain technical support. They may not excel on answering customer questions although they are good coders. How to evaluate these developers? Answering customer’s questions require a good balance of technical skills, people skills and language skills. Developers may not have problems on technical things, but some may have a hard time expressing their ideas in terms of English or any other languages; some may not have the patience to be a good tech support guy. How do you deal with these people?
http://itscommonsensestupid.blogspot.com/2007/12/rotating-support-among-developers.html
2 lior 12 December 2007 @ 2:20 pm
# doing support is a great way to work on parts of the system which in regular development you don’t encounter. This does tremendous job at circulating knowledge around. I would guess that if the current support programmer has difficulty in solving the problem he will get help. However, the responsibility will not transfer. It still his job to locate the fix and answer the customer even if someone else provided the technical solution
#thats something that still need to be fine tuned. But luckily most cases are not of this type.
# Being a good developer requires many skills. I would like to think that even the skills that you mentioned can be learned and improved over time. I also think that these skills are really mandatory for all programmers. Being a good tech support is not beyond any programmer abilities (in most cases).
3 Eli Lopian 12 December 2007 @ 10:43 pm
# We use pair-programming when developers don’t know how to solve a support. Normally a half an hour with the ‘expert’ is enough to get going.
# Long issues are normally handed off (they are normally issues that can’t be reproduced and require communication with the customer). Hard issues are solved by pairing
# Developers who can’t communicate with our customers should grow up and face it. The code is being used by customers and we want an open communication channel.
Simon Jones from the extreme programing mailing list suggests:
1. Have a dedicated person for helping users use the application
2. When defects are found - they are top priority (i.e. halts the iteration)
3. When ’sub-optimal’ features are highlighted - they should be written as a new feature (story).
This might work well in a perfect environment, but practically it doesn’t really work. Here is why.
1. Helping users use the application also might point to a missing feature. 1 and 2 are mixed.
2. It is nearly impossible to know up front if the issue is a real defect or a ’sub-optimal’ feature. Handling support is a different mind frame because of the communication with the customer, and it takes time to pinpoint the problem (and find workarounds)
3. Developers must understand how users are using their application and having someone dedicated will lose this contact.
4. Even if defects are considered top priority, there is no mechanism in agile environments that ‘allows’ pushing these issues into the current iteration
Having support and getting input from the customers is not a sign that the software is bad, it is actually a sign that the software is being more widely adopted and is being used in more egde case scenarios that where not considered with priority at the time of release.
4 Eli Lopian’s Blog (TypeMock) » Blog Archive » Technical Support, our policy pays 24 August 2008 @ 2:44 pm
[…] I have spoken before about our Support Policy, and it seems that it pays off, as good technical support is one of the differential factors when choosing Software tools according to Soon Hui […]
Leave a Reply