DevOps Success via the Service Desk

If you ask what a service desk is you might get any of these responses:

• IT operations or IT service management (ITSM) team: “The team we give the responsibility of dealing with IT issues.” And the more cynical among them might add “… but little in terms of knowledge or tools.”
• Business users: “The people who can help us with our IT issues … some of the time.”
• Development: “A worthless and unskilled part of IT.”

Okay the last one might be over-the-top cynical but the service desk/help desk can struggle to be valued outside of IT operations.

---

The Role of the Service Desk in DevOps

Thankfully, DevOps can help to change and improve this perspective by using the service desk as the pivot point between Dev, Ops, the business, and suppliers. DevOps is the cultural effort of getting Ops to see into the world of development and project teams, while also providing a mechanism for Dev and the project management office (PMO) to better understand the impact of change on production environments and, more importantly, on the customers.

So the service desk can be the lynchpin for how communication, collaboration, and the enhanced use of automation can enable technology to better support business processes and operations.

Think about what the business wants from IT:

• Better features or products, on a more timely basis
• Deployed in a secure, reliable, and cost effective manner
• Supported 24×7

So it is a lot more than just the delivery of new or improved technology.

Positioning the Service Desk in DevOps – the “First Way”

Referring to the book “The Phoenix Project,” by Gene Kim et al, the authors talk of DevOps enablement through three principles or ways.

The First Way ensures the flow of technology (people, suppliers, processes, software, and infrastructure) to the business. In my opinion, many DevOps efforts fail because the concentration is on a flow from “idea” to “provided,” but successful DevOps needs to include a longer flow that includes support and review, in order to enhance future use.

The last thing corporate IT organizations want is a dissatisfied stakeholder or customer who looks elsewhere for technology services. But if companies do not consider the entire value stream, then a suitable analogy would be “The operation was a success, but it is a shame that the patient died.” So the service desk can help IT and the business to be prepared for whatever rate of change is going to occur.

The service desk knows what works and what doesn’t, the sort of issues most end users have, and how best to satisfy a customer. Their input early in the design phase can reduce or remove constraints related to non-development issues, such as having the right equipment available to use the new software, addressing licensing, or helping to train users. The flow is now from “idea” to “valued use” of a new feature, product, or service that retains and attracts customers.

Positioning the Service Desk in DevOps – the “Second Way”

The Phoenix Project’s Second Way is feedback and this is where the service desk can excel – as most of the work performed by the service desk results in feedback:

• Gathering information on technology performance and use
• Knowing how customers or end users react to changes
• Contributing to 2^nd or 3^rd level support requirements
• Capturing customer or end-user requirements or wishes
• Understanding how technology is used on a daily basis
• Acting as the “single point of contact” for training or the creation and maintenance of knowledge artifacts, which can lead to better self-service
• Collating customer complaints
• Using the service desks’ tools and experience to record and track issues across the development to deployment lifecycle
• Facilitating escalations internally or to suppliers

All of this and more can help IT react to issues and, more importantly, to proactively assess whether a new feature or product is worth the effort and cost.

Positioning the Service Desk in DevOps – the “Third Way”

The Third Way is continuous improvement, which means that we learn from our efforts and try something new. This step is not a report with actions that no one ever addresses, but is performed daily by all members of IT. Imagine if from the beginning of the “idea” to “go-live” lifecycle, the service desk:

• Captured all issues
• Began to learn how to resolve them
• Ensured that integration, end user, or production-ready tests confirmed that the issue was resolved, or at least that self-healing scripts worked
• Noted when issues came back and escalated correctly
• Assisted with the automation of processes
• Trained users

Letting the service desk learn, create, and improve their capabilities will let the people, who are first to serve, be fully able to perform that function and, where necessary, gather feedback for improvement of the product.

Ultimately, the service desk is not just the “face of IT” – it is also its eyes, ears, and mouth. Everyone in the organization, even IT, uses it to help solve issues or request equipment or software. The service desk therefore knows the “truth” about IT – the good and the bad, from features and products to customers and suppliers – and can add value by sharing this information early in the design lifecycle.

So DevOps and the service desk should be a perfect fit. How is your organization’s DevOps activities involving and exploiting service desk capabilities?