Print Page   |   Contact Us   |   Report Abuse   |   Sign In   |   Register
Service Management Forum Blog
Blog Home All Blogs
Search all posts for:   

 

View all (5) posts »
 

DevOps and Service Transformation

Posted By itSMF Australia Inc, Wednesday, 7 December 2016
Updated: Wednesday, 7 December 2016

Up to now I had regarded DevOps as something that lived primarily in the Applications Development environment and could never figure out why the ITIL folks were getting all excited about it – in both positive and negative ways. The sessions I went to at the itSMF Conferences, the people I talked to and what I had read on the topic gave me the impression that it was all about getting application releases into production quicker and more efficiently.

Great !!!

But I was wrong ….

When the Chairman of itSMF Australia challenged the Board to write a blog of 500 words on DevOps I actually had to do some reading and research of my own (prodded by some excellent references supplied by Brad) and try to understand what DevOps might mean to me and my organisation.

Interesting enough the two planets were actually aligned because my organisation is constantly looking at ways to improve the way we deliver services to our customers.I certainly have some firm views, based on over 30 years of IT service delivery plus the wisdom and guidance of the ITIL framework.

So what could DevOps add that I hadn’t already thought of?

The article that did it for me was written by John Custy and it was titled “How to enhance IT support with DevOps (Part 1)” – and I didn’t need Part 2 because I got one of those light bulb moments when I got to the bit about CALMS.

In a previous life the acronym meant the Computer Aided Livestock Marketing System (I’ll let you guess what organisation I was working for at the time) but in this context it’s a framework defined by Damon Edwards and John Willis that means:

So why the light bulb moment?

Remember I mentioned earlier that I had some views on the way we could improve service delivery in my organisation?

Well let’s just say the light bulb went on because pretty much the things I thought needed changing aligned very closely with CALMS. Read on while I go through them and think about your organisation along the way.

Culture – I talked about changing the way people think about services and customers, getting out of the loop of “we’ve always done it that way”, working more collaboratively, becoming service focussed rather than technology, getting into a matrixed model and out of the delivery silos. CALMS talks about shifting from silos to constant communication, focussing on results, not just activities and understanding the behaviours of the teams. A pretty close match I think.

Automation – It’s reducing but we still process lots of paper based forms, emails and many of our processes need manual intervention. We have lots of knowledge that would be useful to share that could be done much better and we could use Problem Management and the information we gain from Incident management better. CALMS talks about all this and more, including the need for support teams to help with testing and closer integration with development and deployment activities.

Lean – many of our processes work and have done so for years but we are so busy we haven’t had much time to look at them and see if they could be simplified and/or improved. There is also a natural aversion to admitting failure and hence learning from it. CALMS says we should eliminate waste, always improve and view failure bas a normal part of learning that should be shared.

Metrics – I think that generating some basic metrics quickly highlights which teams are performing well and which ones need help – and ditto within the teams if you go that far. I’m not an advocate of a large number of metrics because I think it leads to analysis paralysis but some basics that tie into the goals and objectives of the team can be very useful. CALMS talks about the time to recover from failure, repeated issues, meeting targets and costs but the overall goal is to keep track of things that matter.

Sharing – knowledge is power and sadly some people don’t share as much as they should because they think it gives them an edge over other people in their team or elsewhere in the organisation. The toolset can be partly blamed but I think the people themselves need to recognise that sharing can make the whole organisation more powerful. CALMS talks about understanding goals, sharing knowledge, communication and toolsets and ultimately wether the rest of the organisation understand what we are doing.

Did the lightbulb go on for you? Can you see the relevance in your organisation?

And finally as Mitchi Tyson taught me – the best most efficient process in the world is useless unless people actually use it. I think that by looking at the things above you stand a better chance of success whether you follow ITIL or DevOps (or both).

Harry Powell

itSMFA Board Member

Tags:  Bulletin  DevOps  itservicemanagement  itsmf  itsmfa  itsmfchair  professional  service management 

Share |
Permalink | Comments (0)
 
Association Management Software Powered by YourMembership  ::  Legal