A couple of years back, I had the privilege of working on a project that delivered 'service desk\u2019 services to the U.S. military. I came in as the owner of service design and, to be honest,\u00a0at 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).\nAnyhow, the project ended (funding stopped, basically) and I moved on to other things. But it wasn\u2019t 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\u2019s examine how I think we worked in a pseudo-DevOps way, and how an organization can use this approach.\nFirst 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\u2019t control that. We sent tickets to fix issues with emails, password resets and so on. But all of that we didn\u2019t control. We had some operational level agreements. (Note the careful italicization of some. Not always, and it wasn\u2019t easy.) But that\u2019s what we did. We controlled what we had in our little sphere of influence.\nSupporting 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.\nThen 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\u00a0service 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.\nThe second value stream was the\u00a0service desk itself, specifically the incident and request management process. In that regard, our\u00a0service desk was throughout the process (open, log, resolve, close) \u2014 except when it wasn\u2019t. That is, when an issue had to be escalated to someone outside of the service desk. Our influence was limited there, naturally, but the\u00a0service desk worked to deliver quality service despite not having full end-to-end visibility of an incident\u2019s life cycle.\nThe 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\u2019t always elegant, or pretty, but we strived to do our very best.\nSo what didn\u2019t we have, from a DevOps perspective?\n\nNo 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.\nWe 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\u2019t a huge part of the project\u2019s DNA.\nNo 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.)\nOur automation was limited and out of our control in some cases. Often, someone would say, \u201cIf we could do X, we could do something faster\/better\/leaner\u201d and then reality would set in. We just couldn't do it.\n\nSo this is a very specific example. A service that didn\u2019t 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\u2019s soul. You can automate many of the things around the\u00a0service 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.\nHow can you use this for your own service desk? Here are a few ideas:\n\nMany 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\u2019m here, may I also suggest looking at the nine principles of ITIL Practitioner? Not perfect, but they may come handy!)\nKnow the value stream of each service and figure out how the\u00a0service desk plays in it. Again, you don\u2019t 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.\nHaving 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.\nThe culture of, and attitudes toward, the\u00a0service 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\u2019s time to see the\u00a0service desk as an equal.\nVisual 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).\nSolving 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.\nSpeaking of flow, identify what a unit of work represents at both the\u00a0service 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.\nFinally, 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. \u201cHow can I help you?\u201d sounds way better than \u201cDo this because I told you to.\u201d\n\nSo in conclusion, I think that many DevOps practices can be done at the\u00a0service 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\u00a0service desk and transport it to the 21st century. Yes?