Bas Blanken
Service Management Consultant & Agile expert
Contrary to what some people believe, the Agile mindset and service management go together quite nicely, as I explained in my previous post blog. But how do you translate the agile philosophy to actual changes in your work? Here are 6 examples.
As opposed to ITIL, agile service management doesn’t provide you with extensive process descriptions you can implement in detail. Agile is a philosophy and based on it you determine how you want to set up your work.
There is of course much to learn from other organizations. According to the agile service management principles by Dolf van der Haven, I’ll give you 6 practical examples on how to make your service management more agile.
1. Make sure everything you do adds value for the customer
IT departments too often put a lot of work into things that have little value for their customers. I recently visited an organization where the IT department had written an extensive manual for a new smartphone they offered. Sounds useful, but most of this information was already available on the internet. And the next OS update is going to make their manual outdated.
A more agile way of documenting is to keep the information in your manual limited to what is strictly necessary and first give these instructions to a small test group. Only describe company-specific information, like how to synchronize your work email with the new smartphone. Do you receive questions from your test group? Update the documentation before you officially start supplying the smartphone.
2. Always work closely with your customers
When designing services or processes, service organizations make a lot of assumptions about the needs of their customers. An example: for years, a facilities organization encouraged their customers to log a call when something was wrong with in the office building. They recently discovered their customers found it quite annoying to receive five to six status update emails after they logged a call. That was the reason many customers decided to stop logging calls altogether.
In agile service management, you involve your customers often and as soon as possible with everything you do. This way, you avoid working based on assumptions. The organization from the example has come up with a solution together with their customers. When customers log a call, they can tick a box saying they want to receive status updates. One question and a single checkbox could have spared five years of frustration.
3. The right people in the right place
Many IT organizations lean heavily on processes. The goal of working with processes is to guarantee a consistent quality of services, no matter who supplies the service. Sounds good in theory. In practice, it does matter who supplies the service. An unmotivated service desk employee probably leaves a less positive impression on the customer than a happy, motivated employee. You can’t cover this difference with a process.
An important part of the agile mindset is having enough time and attention for your team members. Your team only functions well with people who are good at the work they do, and when the work they do makes them happy. Is a team member no longer motivated? Talk to him or her. Maybe they’re happier in a different role.
4. Make your processes as flexible as possible
ITIL processes are usually not flexible. Take change management. A Request for Change needs to go through a set number of predefined steps. The only choice you have in the process is approve or decline. There is no room to change plans. If you want to change them, you need to stop the process, make a new plan and get approval.
Make sure that the processes you design are flexible enough to deal with ever-changing demands. This however doesn’t mean you need to implement every single change during the process. It does mean that you leave room for your team to deal with the processes as they see fit.
5. Design, implement and improve your services step by step
New software or services implementations can take up months, years even. When the implementation is finally done, you’ve gained so many new insights you probably want to change everything. But by that time there’s no more budget left, the project team members have moved on and it’s up to the application manager to process all the feedback on her or his own.
Delivering new services in an agile way means you deliver something workable as soon as possible, collect feedback, and use this feedback to improve the product. At TOPdesk we do software implementations step by step. We first set up a basic version of the call management process, and as soon as it’s operational, we go live. The process isn’t perfect, but we’re okay with that. While we continue working on the next process, we receive feedback to improve call management.
6. Keep your services and operations straightforward
Request process often contain a lot of unnecessary management authorizations. The IT department assumes that management wants control over every individual request. Or the IT department doesn’t carry any responsibility. This makes for a process full of authorizations and a manager who gets loads of emails with authorization requests.
The process shouldn’t be this cumbersome. It works better when the IT department asks the managers how much control they really want or need. They usually don’t really want to receive all those emails. An alternative solution: requests don’t need to be authorized, and managers receives a monthly overview of the costs. This way, the manager still has control over and an overview of the costs, but he or she doesn’t have to process a lot of emails. And the employee is helped quicker.
Tip: just get started and keep it small
I sometimes get the question: where do I need to start when I want to work more agile? To be honest, that differs per organization. Take a close look at your current services and compare this with the agile principles. Where’s the friction? And what improvements are easy to implement? Start there. Make a small improvement. Ask for feedback. And move on to the next improvement. And read our Agile e-book.
Submit a Comment