Where Is the IT Service Desk in a DevOps World?

As more companies move to adopt DevOps practices to improve IT performance (my company included), I was thinking to myself – is it clear how to blend this with our existing IT service management (ITSM) activities? These existing ITSM disciplines and processes, often based around ITIL, have served us well for many years. So although most of us accept that it’s time to adapt, how do we best marry the ITSM, or ITIL, activities and DevOps? In particular, how do we best incorporate the IT service desk in the DevOps world?

In this blog, I want to look at each of the DevOps “three ways” and outline how the service desk can be fundamental to all of them as well as other Agile concepts.

DevOps – The Three Ways

In all definitions of DevOps, the three ways are key pillars to developing IT in a way that better serves customers. By undertaking work and improving through the three ways, DevOps teams can deliver requirements in a faster and safer manner, with all three ways designed to be used together and improved upon on a continual basis.

Source: http://itrevolution.com/the-three-ways-principles-underpinning-devops/

The emphasis of systems thinking is to look at the performance of the entire system, as opposed to that of a specific silo of work, e.g. a department. The focus is therefore on the business value streams that are enabled by IT, not just on IT itself. The key outcomes of systems thinking are to ensure known defects are not passed downstream and that flow is maximized by managing constraints within the system.

Source: http://itrevolution.com/the-three-ways-principles-underpinning-devops/

This is all about creating right to left feedback loops. By shortening and amplifying the feedback loop, corrections are made earlier and more accurately to meet the demand requirements of the customer. The outcome should be responding to all customers and embedding knowledge within teams and individuals.

Source: http://itrevolution.com/the-three-ways-principles-underpinning-devops/

This third way is about creating an atmosphere of experimentation, where risks are taken and failures learnt from, and gaining the understanding that can only be gained from repetition and practice. These are needed to both improve and be able to get out of situations when failures are made. It’s crucial that time is allocated during daily work hours for teams and individuals to do this, as well as providing rewards for taking risks.

What’s the Service Desk Got to Do with All of This?

“That’s all well and good,” you might say, “but what’s this got to do with the IT service desk?” Well, quite a lot actually. To understand what though, you must think more realistically about what your service desk is and what role it really performs.

Let’s look at the average service desk (although I’d like to think that none of us are average): employees are all too familiar with being the last to know about any service changes. They are used to being at the bottom of the IT pecking order and not owning the processes that they use on a daily basis. But what happens if you turn this around? What if you make the service desk the first to hear about the effects of any change? What if you see them at the top of the pecking order in terms of your relationship with the customer with control over the processes they use? Suddenly its place in DevOps is clear.

1. Systems thinking – The service desk already has visibility of the business impact of IT as the first line of support. It is they who speak directly with end users and customers on a daily basis. As a result, they often have a better business process understanding than the rest of IT. If we are looking to understand flow and how best to manage it, the input of the service desk is invaluable.
2. Faster feedback – To create value in this continual interaction, the service desk is ideally placed to provide faster feedback that’s key to successful DevOps. Not only that, but because so much of it is human interaction, the feedback that can be provided by the service desk is often richer and more textured than data-generated feedback by technology alone.
3. Experimentation and learning – Finally, if we encourage a culture of experimentation and learning, then the service desk is at the forefront of understanding the implications and effects of any experimentation. More than this, it’s very much in real time for end users and customers as they call as soon as they see changes – good, neutral, and bad. Also, with control of the incident management process, they can build in steps to ensure the right teams get transparent feedback to fix the results of any experimentation. This in turn can help convince executive-level management that the benefits of experimentation are not outweighed by the cost.

The DevOps CALMS Framework and the Service Desk

In addition to the three ways, DevOps has a framework of five attributes called CALMS – culture, automation, lean, measurement, and sharing. Although the service desk, as part of IT delivery, has a hand in each of these five, there are two that most stand out.

The first is culture. To benefit from DevOps, you need a culture that supports collaboration and communication. As the face of the IT department, the service desk is all about communication –outwards to the business and back in to technical teams. Plus without the collaboration of the service desk, you won’t have a highly effective DevOps set up.

The second is sharing. This means not only sharing practices but also being transparent about findings and data. Since service desk strategy is partly driven by data and the service desk is often responsible for operational reporting, the service desk should play a key role in successfully sharing among teams.

Agile Practices and the Service Desk

In Agile software development, for example Scrum, the decision on what things to work on is done through product and sprint backlogs. This backlog is created by a team comprising product managers, developers, operations, and other staff who agree what work to prioritize. Out of all the IT teams, who do you think has a central role in understanding the tradeoff between business and technology? You guessed it – the service desk of course!

Getting your service desk to feed into, and help shape, both the product and sprint backlogs is vital in keeping its content relevant. In addition, the service desk can also get involved in managing technical debt – the extra development work that’s required when easy-to-implement code is used rather than what’s the best overall solution, i.e. doing what’s easy creates additional problems or “additional interest” later on. Because the service desk plays a pivotal role between the business and IT, they are well placed to understand if the short-term expediency for the business is ultimately worth it.

So an integral and empowered service desk is critical to delivering the benefits that are promised by taking the DevOps pathway. If we leave them out of the loop, as has happened in ITSM too many times before, the negative impact will be far greater than we’ve seen previously. Business and technology engagement is fundamental to DevOps, and the service desk’s role is key.

If you want to read more about DevOps and ITSM, I suggest Please, Don’t Just “Do” DevOps! by my good friend Stuart Rance.

Image credit