Support 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 DA Support mindset
- The support process
- Support strategies
- Support workflow
- Building your support environment
The Disciplined Agile Support Mindset
The following philosophies describe a Disciplined Agile Mindset for Support:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Figure 1. The potential activities associated with Disciplined Agile Support (click on it for larger version).
- Support strategy. How will you provide support services, if at all, to your end users?
- Provide self-service options. Self-support strategies enable end users to support themselves by providing information to them.
- Provide assisted support channels. Assisted support channels provide end users with access to a staffed help/support desk or even to the development teams themselves.
- Escalate incident. Most incidents will be addressed immediately by someone 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.
- Address incident. There are several potential aspects to addressing an incident, including categorizing and prioritizing it, assigning it to the appropriate person(s), and monitoring the status of it if it is not addressed quickly (some incidents take hours or even days to address).
- Architect a support environment. You will need to provide an infrastructure to enable your support strategy. Please see the section architecting your support environment.
- Govern support. Your support efforts should be governed so as to ensure they are effective. This is part of your overall IT Governance and organizational Control efforts.
There are three categories of support strategies – direct assisted support, indirect assisted support, and self service – which may be combined. The strategies are described in the following table.
|Direct assisted support. In small organizations you can take what is known as a direct-support strategy, often called the “you build it, you support it” strategy in DevOps, where end-users contact the delivery team directly for support.||
|Indirect assisted support. Large organizations often have a support/help desk organization providing support to all end users, in some cases routing complicated incidents to the delivery team responsible for a given solution.||
|Self service. Many organizations are offering sophisticated self-service support offerings, including but not limited to discussion forums, online help, how-to videos, tutorials, and more.||
Now let’s explore, at a high-level at first, the workflow for a typical Support engagement. This is depicted in Figure 2, and from our point of view it’s a two-step process:
Step 1: Self service. The first step, we hope, is for the end user to attempt to solve their problem themselves. In many cases the end user will ask their colleagues for help and will often get it, particularly when the end user has an issue that an experienced end user understands. When this doesn’t work the next thing the end user should do is take advantage of your self-service offerings, such as online help, an FAQ, online videos, and so on. Hopefully your self service offerings are sufficiently robust so that they don’t have to contact your assisted support options (which are expensive).
Figure 2. High-level view of the Support workflow (click on it for larger version).
Step 2: Assisted support (if needed). Let’s start with the more common, indirect support version of this step. In this case an end user engages with the support desk, perhaps by calling in or via a chat system. 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 (now this has evolved into direct support by the development team, more on this in a minute).
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.
Figure 3. Detailed view of the Support workflow (click on it for larger version).
Now let’s explore direct support, depicted below in Figure 4. This strategy tends to occur in two situations:
- Escalation. As described above, an incident gets escalated to the development team from the support team. This development team may be a sustainment team who at some point in the past has taken over responsibility for the system from the original development team.
- DevOps. It may be the case that the original development team took a stable, product team approach to development where the team sticks around and continues evolving and supporting their work. In other words, they’re taking a “you build it, you support it” strategy that is common with a Disciplined DevOps approach. Having developers interact with end users can be expensive, but it also has the benefit that developers directly learn about what end users are struggling with, which in turn tends to lead to them developing better solutions in the long run.
A significant challenge with direct support by developers, particularly when there isn’t a help desk between the end user and the developer, is that developers can get quickly overwhelmed if there are usability or other quality problems with their solution. Having said that, it’s arguable that they should get overwhelmed with requests in this situation to better understand the impact of their work.
Building Your Support Environment
An important aspect of Support that is easily forgotten is the need to build out your infrastructure to support your support efforts. This may include:
- Creating a support knowledgebase so that your Support Engineers can capture solutions to the problems they solve.
- Provide access to the support knowledgebase to support self-service by end users. This access is often limited for privacy reasons – end users should have access to solutions to common problems but not the details to specific incidents.
- A support environment to simulate problems. In some cases, such as an online trading system perhaps, you don’t want your Support Engineers trying to diagnose end user problems on the live system itself due to potential side effects of doing so.
- Installing communication systems such as chat software and a phone/call in system.
- Automated support systems such as integrated voice response (IVR) and artificial intelligence (AI)/bots
Figure 5. High-level architecture for a Support environment (click on it for larger version).
Your IT support efforts are a critical aspect of your overall IT services provided to your organization. As with other process blades you have choices, and every organization will tailor their Support strategy to meet the needs of the situation that they face – one process size does not fit all.