Support

Support/Help Desk process bladeSupport is a process blade of Disciplined DevOps and Disciplined Agile IT (DAIT). Your support activities, sometimes called Help Desk or End-User Support, focus on helping end users to work with the solutions produced by your delivery teams. Ideally your solutions should be designed so well that end users don’t need anyone to help them but unfortunately it doesn’t always work out that way. So in many ways your support strategy is your “last line of defense” in your efforts to Delight Customers.

This article is organized into the following topics:

 

The Disciplined Agile Support Mindset

The following philosophies describe a Disciplined Agile Mindset for Support:

  1. Avoid problems to begin with. The most effective support calls are the ones that you didn’t need to have in the first place. You can reduce the number of problems that people encounter through better user experience (UX) design during development and by building a trustworthy IT infrastructure (see earlier). It is critical to recognize that any money spent on support is addressing failures as opposed to adding value.
  2. Provide self-support strategies. With the advent of free online software such as Google Mail, Facebook, LinkedIn and more people have effectively been trained to support themselves in many cases. These techniques, such as providing online information and online discussion forums, can be employed for both customer-facing as well as internal-facing systems. Providing robust self-support options can both dramatically reduce the number of requests to your help desk and improve end user satisfaction with your solutions. A very good strategy is to post videos on YouTube describing ways to get better value out of your solutions or to address common problems that people run into.
  3. Favor proactive support over reactive. Self-monitoring systems can now detect many problems as they occur in real-time, and often recover from those problems before your users even notice. But, in some cases it may be likely that the end user has been affected by a problem. In this case you may choose to apologize for the potential problem and ask the end user if they would like help from a support engineer.
  4. Have two-way conversations. A key skill for anyone doing support is for them to strive to have real conversations with the end users that they’re helping and not just be order takers capturing a problem description. The idea is to find out what they are trying to achieve by using your solution, to identify what is working well, what isn’t, and what is potentially missing from the solution. In other words, get a sense of what end users want to accomplish so that you can better deliver value to them. Support engineers are often some of the best stakeholders for a solution delivery team because they have the most contact with actual end users and therefore will have significant insight into what they need.
  5. Solve the problem. When end users decide to contact your support help desk the support engineer should take responsibility for the problem, explain what happened and what the process is to resolve the problem, and then see it through until the problem is resolved to the end user’s satisfaction.
  6. You build it, you support it. The DevOps philosophy of “you build it, you run it” applies to Support activities too. In small organizations, or at least those with a limited number of products, it is common to see the delivery team itself staff the support desk for their solution.

 

The Support Process

Some methods will choose to prescribe a single approach to Support, but the Disciplined Agile (DA) framework promotes an adaptive, context-sensitive strategy.  DA does this via its goal-driven approach that indicates the process decision points that you need to consider, a range of techniques or strategies for you to address each decision point, and the advantages and disadvantages of each technique.  In this section we present the goal diagram for the Support process blade and overview its decision points.

The following diagram overviews the potential activities associated with Disciplined Agile Support.

Disciplined Agile Support

The process decision points that you need to consider for Support are:

  1. Support strategy. How will you provide support services, if at all, to your end users?
  2. Escalate incident. Most incidents will be addressed immediately by the person in the role of Support Engineer (which in the case of a “you build, you support it” DevOps-style approach would be someone on the delivery team who built the solution). Sometimes, when an incident is too complex, it may need to be escalated to others with greater experience or knowledge.  This is discussed in greater detail in the organizing your support desk section.
  3. Address incident.
  4. Govern support.

 

Organizing Your Support Desk

In small organizations you can take what is known as a direct-support strategy, an extreme form of the “you build it, you support it” DevOps approach where end-users contact the delivery team directly for support.  This strategy works for small organizations with a small number of products that in turn have either a small number of users or users that are very sophisticated in the use of your product.

The direct-support strategy doesn’t scale very well, as you could imagine.  A better solution for organizations where you have many offerings to support or users that measure in the thousands to hundreds of thousands is to have a support/help desk organization.  These organizations tend to have a common help desk providing support to all end users. An end user engages with the support desk, perhaps by calling in or via a chat system.  Often they will have tried to resolve the issue/incident themselves via self-service support features such as online-help or discussion forums.  The front-line support engineers provide “level 1” support and handle most incidents on the spot. Sometimes an issue is too complex for them to handle, or perhaps they don’t have the authority to resolve the problem, so they bump the incident up to “level 2” support, which is typically a more senior support engineer or even the support manager.  Many incidents are resolved at this level.  Sometimes an incident requires someone on the delivery team to address it, so it is escalated to “level 3” support.

Support escalation process

Some organizations have a “touch and hold” strategy where the support engineer who accepted the initial request for help stays with it throughout any escalations.  Sadly many organizations do not take this approach and hand off the issue from one person to the next, with the potential for the incident to get routed to the wrong person or even dropped.

When you are dealing with very large numbers of end-users, in the millions or even hundreds of millions, a “Support-Desk” staffed with people doesn’t scale well either.  In these cases you will require sophisticated self-service support offerings so as to dramatically reduce the number of support desk requests that you receive.  The offerings may include discussion forums, online help, how-to videos, tutorials, and more.