This blog entry is part 2 out of the series, where I discuss the process to structure support and maintenance work, at JTeam.
In the previous part (part 1) of this series, I’ve discussed our first setup for a support structure in our company. As I said, this setup is not used anymore due to several reasons. In this blog post, I’ll clarify these reasons and take you in on our second setup of the support structure.
Keep in mind the original problems we had to tackle to improve our support initiative:
- Knowledge stays within a select group of people. These people are not always available (e.g. when working on other projects). When these people are on holiday, sick or leave JTeam, work cannot continue. So, the ability to solve problems, or adding new features, depends on the availability of those people. JTeam becomes dependent on them.
- People keep working on the same project over and over again which can become kind of tedious in the long run.
Since the launch of version 1, we experienced some difficulty in realizing this plan. This was mostly due to the fact that people are outsourced, being unavailable at the office, or inability to get people away from the customer to take on the job of support member at JTeam. Depending on the customer, it is rather difficult to tell/ask a customer that our ’empowering’ colleagues working on their project should return to the JTeam office to handle support issues.
Secondly, it is a big risk for JTeam to have three people working on support, situated at JTeam HQ, with the risk of not having any support call to handle. They can fill up their time with researching innovative technologies or writing blogs, all also *very* valuable for JTeam, but they don’t do any billable work. Eventually this will simply cost too much money.
Third, mainly because of the first point, a lot of the same people were assigned support duty, which made the knowledge transferring requirement obsolete.
(code name : only the lonely)
To solve the availability problem, we changed the process in a way that availability is not an issue anymore. In this version, one person, each week, a whole week, will function as the first contact for support calls. This person will gather all support calls and might directly know how to solve the problem or checks if a solution is already documented on our company Wiki (Confluence). If so, this person can help the customer immediately. If not, the call will be forwarded to the team of people knowing the most of this project. It is the responsibility of the support person to check up on/manage the person handling the bug. The Project Manager of this project can do this as well, but it remains an important task of the support person.
In practice this means that the first contact will listen to our support email address and picks up issues from there. If this person fixed it, and thinks the solution to this problem is handy for reference, he has to document it on Confluence, so the next person scheduled to be first contact can benefit from that information in the future.
But…how do we let the customer contact support?
Project managers will still receive emails and calls from customers, since they are used to calling a specific person. And they should. The development team can change, but the customer needs one contact person which knows about their functionality and can help them with requirements and decisions. In this case, the project manager takes note of the call/email, maybe already answering, and forwards the support call to the support member for further handling.
Since, as a support person, you only have to listen to the support email address, people who work at the location of a customer, can also function as the first contact. To the customer will be communicated that it can happen that you have to answer some emails, or put other people to work. For the customer, this is more acceptable, then having a member of their development team, leave the team to be at JTeam for three days to handle support. As was the purpose in version 1 of our support process.
Next to the above process, we also have some technical infastructure to facilitate our support process. Problems that are issued by email, are directly and automatically logged into our issue tracking system Jira, so the customer and the development team have a reference of the problem at hand (see a future blog post about the Jira setup).
This way of work allows us to make a planning upfront for the person who is going to be the 1st line helpdesk person for what week. Depending on the internal vacation schedule we planned a week for everyone. The schedule is publicly available, and rescheduling is always possible if it is mentioned upfront!
So, if a lot of support calls are still assigned to the person with already the most knowledge of the project, how do we address the knowledge sharing and transfer issue? Not one person should have all the knowledge of the project! You’re right.
Well, to solve this, when new features are to be created for these support projects, someone who is available will be pointed out to pair program / learn from the master himself. This way knowledge is transferred and more and more people will understand the code of the project, so every time even more people can pick up issues for this project.
Knowledge transfer is important. If, in the team planning meeting, we know that some work on new functionality is planned for a support project, we will check to see if someone with less knowledge of that project is available to learn from the person who is implementing the new features. This can for example mean, that people that work at the customer 4 days a week, will work on some new features of a support project, the day of the week they are at JTeam. This way everyone will be familiar in a way with the projects at JTeam.
this is the plan for now and is currently used at JTeam. As a true agile and pragmatic company, we’ll evaluate in a couple of weeks and review how this worked out in practice. If our structure is being modified I’ll let you know of course !
Any remarks and suggestions about our current support process, or other ways of implementing a decent support structure, are more then welcome.