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?