Accidental ITIL and DevOps

A couple of years back, I had the privilege of working on a project that delivered ‘service desk’ services to the U.S. military. I came in as the owner of service design and, to be honest, at the time I thought that the way the project was laid out seemed off. I thought nothing of it after getting in stride. I did my design work as best as I could, and the project was basically working well (or as well as a government project can run).

Anyhow, the project ended (funding stopped, basically) and I moved on to other things. But it wasn’t until recently that something finally clicked: We were doing elements of DevOps without knowing that we were doing it! To me, it was an eye-opening revelation (and no, I didn’t bang my head against a wall). Let’s examine how I think we worked in a pseudo-DevOps way, and how an organization can use this approach.

First things first: We had a very narrow scope of service. We were a service desk. Period. We took calls, logged incidents and escalated. We strived for that magical first call resolution number by providing agents with as many tools as we could give them. Not easy (government, you know?), but we tried. That was it. We could escalate tickets to onsite techs, but we didn’t control that. We sent tickets to fix issues with emails, password resets and so on. But all of that we didn’t control. We had some operational level agreements. (Note the careful italicization of some. Not always, and it wasn’t easy.) But that’s what we did. We controlled what we had in our little sphere of influence.

Supporting the service desk, we had a group of people aligned with the ITIL life cycle: design, transition, operations and CSI. We worked together as a team to figure out how to resolve issues that came up after missed escalations, angry officers and so on. But we were a cross-functional team that sat together to figure these things out. This was my first indicator that we were sort of organized in a “DevOps” fashion around a simple, single scope of service. Barring any differences in opinions as to how we fixed things (oh, we had many!) looking at it from the rearview mirror I think we were organized the right way.

Then comes the issue of flow. I was thinking hard about what would flow look like in this arrangement and I see two distinct value streams: One that we controlled and one that we did not. The one that we controlled was related to the ITIL life cycle itself. We had interactions where we had the design people (me), transition people (change, configuration), operations (where the actual service desk was managed) and CSI. We spoke about issues and strived to resolve them. So, in retrospect, our unit of work was any sort of “issue” with the service desk, which can be translated to any desired improvement.

The second value stream was the service desk itself, specifically the incident and request management process. In that regard, our service desk was throughout the process (open, log, resolve, close) — except when it wasn’t. That is, when an issue had to be escalated to someone outside of the service desk. Our influence was limited there, naturally, but the service desk worked to deliver quality service despite not having full end-to-end visibility of an incident’s life cycle.

The other thing we had was management commitment. All (or almost all) of the people responsible for the service were committed to its success. They paid attention and, when issues were identified, we acted to ensure that our service was delivered to our agreed targets. That commitment trickled down to every resource in the project in both directions. It wasn’t always elegant, or pretty, but we strived to do our very best.

So what didn’t we have, from a DevOps perspective?

• No daily stand-ups and no visual management. We had the typical daily or weekly meetings, but nothing that resembled a 15-minute day stand-up, for example. I do believe that agents had a preshift briefing, to let them know if there were any issues they had to be on the lookout for, but they certainly did not have a board.
• We improved, but very often only after we got hit, yelled at or kicked. Doing continuous improvement, as laid out in current DevOps thinking just wasn’t a huge part of the project’s DNA.
• No culture of fail-forward. We failed, and got blamed. (Note: this may be a cultural issue that would have been out of our control even if we were ace DevOps practitioners. But still, an important point.)
• Our automation was limited and out of our control in some cases. Often, someone would say, “If we could do X, we could do something faster/better/leaner” and then reality would set in. We just couldn’t do it.

So this is a very specific example. A service that didn’t deal with code or servers. It dealt with people. So it is not as sexy as, say, spinning up a gajillion servers in half an hour, or deploying code to production at the blink of an eye. People are fickle (some more than others) and the service desk, specifically, is the window to the IT organization’s soul. You can automate many of the things around the service desk (self-service, mobile apps) but in the end, and in many cases, you need to deal with a human on both sides of the equation.

How can you use this for your own service desk? Here are a few ideas:

• Many IT organizations try to support every IT service they deliver. Have you ever tried handling four or five beers at a basketball game for you and your buds? How do you think that is going to end up? You can imagine what happens. What you do is identify those core supporting services and vital business functions and focus the service desk on that. Does that mean having multiple service desks? Not really; it’s certainly a possibility, though, but it’s not a hard requirement. Use an arrangement that works for your organization and use ITIL as guidance not cannon. (While I’m here, may I also suggest looking at the nine principles of ITIL Practitioner? Not perfect, but they may come handy!)
• Know the value stream of each service and figure out how the service desk plays in it. Again, you don’t need a value stream map for every service you do (see the bullet above); just for the ones that matter in support of a vital business function.
• Having a cross-functional team working on improvements at each life cycle phase in support of the value stream is crucial to the success of this. You have to have people in close relationships, even close physically, to make this work. And, yes, that includes the service desk.
• The culture of, and attitudes toward, the service desk have to change. Historically, service desks have been visualized as the proverbial throat to choke, while other elements of the service(s) they support often “get away” with issues at their level. It’s time to see the service desk as an equal.
• Visual management is a great way to make information visible and available at all levels of the organization with some teams needing more structure than others. Use a level of management that makes sense for the team and that does not become a burden to maintain or to update, understanding that one of the benefits of visual management is the flow of information both ways (i.e., to and from management).
• Solving problems should be a priority for those working with services at every life cycle stage. And by problems I am not referring to the process of problem management per se, but those issues that impede the flow of a unit of work through the value stream.
• Speaking of flow, identify what a unit of work represents at both the service desk level and at the life cycle level. What does that look like? Maybe it is an improvement to a service, or a design change. Make sure everyone understands that and what it means for the value stream.
• Finally, management needs to be 100% committed to working and learning and to the need to become people who empower as opposed to people who bark orders. “How can I help you?” sounds way better than “Do this because I told you to.”

So in conclusion, I think that many DevOps practices can be done at the service desk level. To me DevOps is, in addition to cool technological things, a change in the way people think. Maybe it’s about time that we supercharge the service desk and transport it to the 21st century. Yes?