DevOps Strategies: Support

DevOps Practices - Support

In this blog posting, part of our continuing series on DevOps, we explore solution support strategies. There are several solution support (help desk) strategies, which can be combined, that you may choose to adopt. These options are:

  • Online information. A very common “self serve” support strategy is to develop and maintain online assets such as frequently asked questions (FAQ) pages, training videos, and user manuals to name a few. This enables end users to potentially support themselves, although suffers from the TAGRI (They Ain’t Gonna Read It) syndrome.
  • Online discussion forums. Many organizations choose to implement internal discussion forums so that their end users can help each other in learning how to use their systems. This is effectively a collaborative self-serve support option for end users. The primary advantage is that your “power users”, or in some cases members of the development team, will come to the aid of other users who are struggling with an issue. A potential disadvantage is that you risk your discussion forum becoming a complaints forum if problems aren’t addressed in a timely manner.
  • Asynchronous support. With asynchronous support strategies an end user will put in a request for help and then sometime later somebody gets back to them with help (hopefully). Common ways to implement asynchronous support include implementing a standard support email or a support request page/screen. It is common in many organizations to put a service level agreement (SLA) in place putting limits on how long people will need to wait for help.
  • Synchronous support. With synchronous support strategies end users are put in contact with support people (who may even be one of the application developers) in real-time. This is often done via online chat software, video conferencing, or telephone calls. The key advantage of synchronous support is responsiveness. However, synchronous support can be expensive to operate and potentially frustrating for end users, particularly when the support desk function is outsourced to people following scripts.
  • Support alerts. With this strategy your solution itself detects serious problems affecting end users, such as a data source or a service/component being unavailable. When such an event occurs, and the solution isn’t able to swiftly recover, the end user is informed of the problem and presented with a “Would you like help?” option. If yes, they are put in direct contact with an appropriate support person who then helps them in real-time. This is part of your solution’s self-recovery process.
  • Developer-led support. This strategy has development teams performing the support services for their own solutions and was described previously in DevOps Strategies: Development.

In the next installment in our DevOps series we will describe release management strategies.

Have any Question or Comment?

2 comments on “DevOps Strategies: Support

Hi. I’ve read the first book on DAD and, in my company, we are starting our DAD journey in the sw development team.

First question: Are You planning to apply the same DAD concepts (roles and processes) to the support?
For example: for the application support (so called Help Desk) we could have the Support Owner who deals with clients (he/she mimics the PO), the Support Leader who deals with the support team members (he/she mimics the TL), etc. The scrum for support tickets can still leverage the priority queues (expedite, intangible, fixed delivery date, business value) and kanban boards, even some “scrum rituals” – like stand up and retrospectives – can be applied as well (mainly in order to build a solid team). Could You elaborate a little bit more on DA application support?

Second question: How do you plan to apply agile to IT Infrastructure support?
In my company the IT infrastructure support is maily based on the ITIL service operations procedures (incident management, problem management, change management, etc.) BoK, so my feeling is that today I can immediately “export” from the DAD the PO and TL roles adapting actual ISO procedures but .. we will have to destroy the actual trouble ticketing system (TTS) queues (made of incident queue, problem queue, change queue, ..) in order to have a completely different queuing system based on priority; my worry is that understanding the process we are treating will become harder than before. Could You elaborate a little bit more on DA infrastructure support?

Thank You in advance for Your kind reply.

Best regards


1. Yes, have you had a chance to see our writeup on the Support process blade? See
2. Sort of. There is also an IT operations blade at , and Release Management at


Leave a Reply

Your email address will not be published. Required fields are marked *