WIREDGOV

Blog posted by: Nikola Gaydarov – director IT Service and Project Management, Rueger Consulting, 07 March 2018.

How agile are we in IT service management (ITSM)?

I’ve seen numerous different companies claiming to be agile while – in reality – they’re not.

If we refer for a moment to the ITIL Continual Service Improvement (CSI)model, the first step is to define the vision and propagate it clearly to everyone in an organization. Companies will fail strategically if top management claims something but the people at the frontline don’t share the vision.

So, claiming to be an agile company means that everyone should have the same mindset: being open to new things, being able to improvise and know you’re all working together. And it also requires thinking beyond agile as a “tool”; it doesn’t make sense if IT is agile but the business isn’t and vice-versa.

Some may think of agile as “only for software”. However, we all have to be agile in ITSM as business is moving in so many different directions and needs our support.

Applying agile

Agile as a methodology might not apply in every situation. However, I do think that agility is a key value in our daily life (in other words, agile, with a small “a”)

Another concern when talking about agile is that people assume it means working at “warp speed”. I don’t believe that – with agile – speed is a goal in itself.

There is the right level of speed and it’s different for every customer of IT and IT service management. For example, a bank has a different expectation of speed to a start-up business. What is important is the predictability of the outcome which both parties agree on.

The business and IT should work like clockwork, synchronized and moving at the same speed to gain benefits along with transparency and no fear. In other words, the quicker the better is not really the case in agile: for customers it’s not always critical that things are delivered quickly, even though they might say it’s critical at the time!

Transparency, openness and agreement

IT organizations need to be transparent rather than hiding behind reporting and dashboards, claiming that “IT is complex” as a reason for not explaining themselves.

For example, in Scrum planning meetings there is a product owner, the Scrum master and team: the emphasis is on transparency and respect for each other, showing openness, respect for opinions and willingness to collaborate and understand each other’s requirements. At the end, everyone is in agreement and the work can progress.

Outcome versus output

Ultimately, the business needs to achieve its outcome and that’s the way it will measure the effectiveness of ITSM. So what is the role for the output?

To draw an analogy, the “output” of a marriage between two people could be described as signing the marriage certificate and holding a wedding reception while the “outcome” is loving each other, perhaps having a family and growing old together. Is the outcome possible without the output – yes!

Running your ITSM shop, of course, involves delivering outputs through processes. And they need to be good to have good outcomes. However, agility comes more into play when you are focusing on the outcomes: the difference is how you move through the steps and run the processes, ensuring that you focus on the outcome the business expects.

Read AXELOS Blog Posts from Nikola Gaydarov

ITSM into 2018: drinking from the well of training and development

What is Agile ITSM and what does it need to be successful?