5 Ways Agile Devops Teams Can Support IT Service Desks

Agile development teams aim to develop innovative capabilities, while devops teams strive to release code to production more frequently. But the buck often stops with the IT service desk and customer support teams who must respond to application incidents, issues, and requests.

Release too frequently with defects, performance bottlenecks, or security issues, and end-users may inundate service and support teams with incidents. Even when devops teams deploy reliable changes, they still have a responsibility to aid support teams in providing excellent customer service or end-user support.

What does that look like in practice? It requires a holistic release management process where a production deployment isn’t marked as done until there’s feedback from support teams on the deployment’s overall success and an understanding of the issues.

To achieve this level of collaboration, agile development teams committing to a devops culture should consider the following best practices.

1. Define and set expectations around high-quality releases

This may seem obvious, but in practice it eludes many development teams because of the complexity of the environments, business demands to release capabilities too quickly, or gaps in testing.

All too often, I find a cultural gap. If you release code today but must patch it a day or two later because of defects or end-user support issues, is the original release labeled a success? The answer should be no. Once the devops team releases, there should be an expectation that the deployment is high quality and the team can move on to the next set of development priorities. Once the team agrees to patch, perform an emergency “break-fix” release, hotfix, or execute an unscheduled deployment, the team should label the original release as a failed or degraded deployment.

This principle encourages devops teams to review application flows, improve test automation, develop more robust test data sets, employ shift-left security testing, and invest in feature flagging.

2. Communicate deployment schedules and share release notes

Ask many customer support and IT service desk teams about deployment schedules, and they’ll tell you they are often the last to know about the development teams’ plans. People working in these functions often don’t have access to Jira, Microsoft Teams, Jenkins, or other tools devops teams use to plan and execute releases. Even when devops teams configure email alerts to inform support teams about planned and executed deployments, the emails and release notes are often filled with unhelpful technical jargon.

Devops teams should specifically tailor planning, release, and deployment communications or collaborations to their audiences. For service desk and customer support teams, communications should focus on how the release impacts end-users.

Devops teams should also anticipate the impact of changes on end-users and educate support teams. When an application’s user experience or workflow changes significantly, bringing in support teams early to review, understand, and experience the changes themselves can help them update support processes.

3. Invest in application monitoring and AIops

Let’s consider two scenarios. One devops team monitors their multicloud environments and knows when servers, storage, networks, and containers experience issues. They’ve centralized application logs but have not configured reports or alerts from them, nor have they set up any application monitors. More often then not, when an incident or issue impacts end-users, it’s the service desk and support teams who escalate the issue to IT ops, SREs (site reliability engineers), or the devops team.

That’s not a good situation, but neither is the other extreme when IT operational teams configure too many systems and application alerts. One incident may trip dozens of monitors and alerts, making it difficult to determine the underlying cause and select a course of action. In this scenario, the IT team may benefit from implementing an AIops solution, such as Big Panda or Moogsoft, which aggregates alerts, applies machine learning to correlate monitoring data, and automates steps to address common issues.

The goal should be to minimize the impact on end-users and reduce the conditions when they have to open support tickets for application incidents.

4. Provide self-service admin tools, query capabilities, and reports

Here’s another application development principle: Avoid releasing features that don’t have administrative tools, workflows, or reports to support end-users. Agile product owners are quick to prioritize developing a feature but are sometimes slow to invest in its support functions.

It’s not “good enough” if service desks or support teams must open tickets with other areas of IT to run a query, export data, manually change data in a database, or run a batch job. These are all forms of operational or technical debt.

Agile product owners should treat the service desk and support teams like other stakeholders and should capture and prioritize their requirements. Ideally, agile principles or governance defines what tools are required, when new capabilities get investment, or when existing featured are enhanced.

5. Review service desk tickets and prioritize fixing defects

IT executives ask development teams to be data driven, and a good place to start is to schedule regular reviews of issues and requests reported to the service desk and customer support teams. Ideally, devops teams should look to automate flows from the service desk ticketing system as either defects or feature requests into the agile development teams’ backlogs.

Agile development teams should use this feedback to prioritize their backlogs. Leveraging feedback, especially from customers and end-users, is a key tenet of scrum and other agile methodologies.

Development teams should look at these issues from several vantage points. Some systemic issues impact many end-users or result in multiple service desk tickets, making it easy to prioritize improvements. Others are like needles in a haystack, but these outliers still impact strategic customers or critical business processes.

Development teams may have limited time allocated to address all the issues, but there may be other options to provide workarounds, simple operational tools, or better documentation to aid service desk employees.

Sometimes, it can be enough to be empathetic to people working at the support and service desk and on the front lines with customers and end-users. So before adding a new feature, improving the CI/CD (continuous integration/continuous deployment) pipe, or spiking on a new technology, consider these best practices that can improve end-user satisfaction and assist the service and support teams.