Print Page | Contact Us | Sign In | Join
The ITSM View
Blog Home All Blogs
This blog, written by itSMF UK leaders and guest contributors, offers service management thought leadership and discussion of industry trends. Please feel free to comment on these posts (you will need to be logged into the website as a member). We look forward to hearing from you.


Search all posts for:   


Top tags: ITSM  ITSM16  PSMF  Q&A  Service Catalogue  SIAM  business change  Career  DevOps  Podcast  problem management  Release Management  Service Transition  SITS16  Are we the wrong people in IT  Automation  BCS  CGI  Digital Transformation  Event  EXIN  IOE  IOT  ISACA  IT4IT  ITIL  ITSM15  Managing Complexity  Metrics  Organisational change 

Getting Practical with DevOps

Posted By Daniel Breston, 10 May 2017

Recently I had the privilege of being asked to develop and subsequently deliver an itSMF UK workshop on “Practical DevOps” explaining:

  • What is DevOps?
  • How does DevOps blends Agile, Lean, Theory of Constraints (ToC), and IT service management (ITSM) into a common framework?
  • The value and principles of DevOps
  • Metrics that matters to DevOps
  • DevOps concepts like Continuous Integration and Continuous Delivery
  • Practical tips related to DevOps success

A Day of Post-it Notes

The workshop was designed from the very beginning to be interactive so no segment went without an exercise. For instance, as we went through the history of DevOps, I asked participants to write their own definition of DevOps on a post-it note. The answers were quite revealing in that most concentrated on the automation aspects of improvement, or just commented upon the need to align Dev teams with Ops/ITSM teams. And by the end of the day, their views had changed to be inclusive of stakeholders, vendors, and all aspects of technology service and delivery.

In fact we used post-it notes in several exercises and the group soon began to see how important visualisation was to DevOps. We used post-it notes to:

  • Create a manifesto of DevOps that was relevant to them (which they then compared to the Agile Manifesto and were amazed at the resemblance)
  • To map the flow of service provisioning from the time the idea gets requested until it’s delivered. We used a Lean concept called Value Stream Mapping and created an alignment charter, visualising the current way of working with time and quality measures, mapped the future, and highlighted some iterative experiments that could be performed in each two week sprint.

Flow of Work

All of the participants were looking at introducing Scrum into their organisations. This picture (from The DevOps Institute) highlighted the view of including not only new or feature related work into your product backlog, but creating a process, the removal of technical debt, and improvement ideas. 

So, Metrics: Do They Matter

So, back to the workshop, using Service Level Agreements (SLAs) as an example, we discussed metrics from an ITSM view and then again from the speed and quality view of DevOps. The group created metrics, using templates on how the automation of a process could help reduce MTTR (incident time) or make collaboration better across teams by automating trust to reduce the need for a Change Advisory Board (CAB).

We reviewed Key Performance Indicators (KPIs) and how to align metrics top down and out to suppliers via a Lean technique called Catch-ball.  Finally the group used their templates to create their own KPIs that they would introduce the following day at work. The template highlighted who owned the metric, the formula, the reason, frequency, what to do if the measure was breached, and the benefit of this measure.

This discussion highlighted again the principles of flow, feedback, and learning against the culture and knowledge sharing engendered by DevOps.


Tips and ITIL Principles?

Finally, we reviewed practical tips on how to get started such as:

  • Organisation: don’t immediately create a team but instead look at how to pilot DevOps practices in your existing organisation.
  • Processes: all processes at some point can be automated and DevOps enables the iterative use of tools to help create faster ways of doing things.
  • People roles and skills: cross-functional sharing, training on not only the new tools but also cultural change, and leadership coaching are all needed.
  • Tools: collaboration and knowledge management is as important as testing and release/delivery automation.

The final part of the day reiterated that ITSM is a valuable part of DevOps (as often mentioned in The DevOps Handbook). We did this using the “9 Principles of ITIL” as documented in ITIL Practitioner.

At the end of the day, participants went away with a better understanding of DevOps, how it works with ITSM, and how to measure its success. The key takeaway was to try something new and iteratively introduce the practices of DevOps into their own organisations.

So how much do you know about DevOps? Would it be of value to you to learn more? I hope to run this workshop via itSMF UK again in the near future, and it’s also available as an in-house event. For more information email itSMF via Or come and speak to me at the itSMF UK stand at the Service Desk and IT Support Show next month.

Plus, it’s worth noting that itSMF UK are also running a “DevOps simulation event” on 5th July, which you can see more details on here.

In the mean time you might find some of the following resources useful:



Tags:  DevOps  Workshops 

Share |
PermalinkComments (0)

How to Support the Innovation Mandate with DevOps

Posted By Robert Stroud, 25 May 2016

DevOps isn’t the answer to every business demand, but it might be the best way to keep up with the accelerating rate of change.


Travelling in Norway following a chapter conference there, I was undertaking some research for this article. As I searched the relevant web page, which was delivered to me in Norwegian, I was immediately asked if I wanted it translated. Shortly afterwards as I was looking for a hotel, I was immediately shown hotels close to my position. Location services and related technologies – determining from the available information who and precisely where the user is – are now becoming prevalent in all aspects of the online user experience. Indeed, they are at the centre of business solution design in a customer-centric era. It’s an era of disruptive technologies and rapidly evolving business models, and what continues to surprise me is the rate of acceleration in technological solutions to deliver business outcomes in ways that IT could not have imagined a couple of years ago.


This acceleration is creating significant issues for many CIOs and senior IT managers. Many have not yet realised their return on investment in existing solutions and are being pressured to accelerate their pace of change faster than ever before. The outcome in many cases is business management who claim that IT cannot react and deliver in a timely manner and then choose to source the technology via another route!


This has led to the rapid adoption of agile development methodologies to meet quickening business change requirements, and many IT organisations are looking to DevOps as the answer to their problems.


DevOps as the name suggests is a merging of Development and Operations. DevOps asserts a philosophy that removes barriers between the development and operations functions, allowing the rate and pace of change to accelerate across the business. The question that I am often asked by ‘disbelievers’ is whether DevOps is simply a strategy to give development and the business the right to skip the proven change processes and avoid the rigour of operations and its investment in current service and project management best practice.


This could not be further from the truth: DevOps is a business-centric philosophy to deliver business outcomes.

Tweet: #DevOps is a business-centric philosophy to deliver business outcomes - @RobertEStroud #ITSM


Speaking to the CIO of a large manufacturing organisation at an industry conference, he mentioned to me that their DevOps initiative is being led by the operations function, who are looking to accelerate the pace of change through pre-production testing to production, even to the point of automation of change reversal where change doesn’t quite deliver the desired results (this depends on processes being implemented to automatically validate change once in production).


The point is that IT needs to react and challenge current philosophies and framework implementations. DevOps is a philosophy that supports rapid innovation and IT-powered business change but it is not a panacea.


So how do we work with DevOps to accelerate our rate of change and overcome the resistance of the existing culture, and what techniques do we use? I thought that I would share some practical steps leveraged by other organisations to commence the journey:


Create a leadership DevOps advocate

Let’s face it, most organisational structures are overly complex, and red tape is often the primary obstacle to success. The first stage in the cultural change is to create a role for a senior executive who has power across the full IT domain to evangelise and sell the organisational benefits of DevOps.


Create the team

DevOps by its very nature is a combination of development and operations. Therefore, DevOps requires a cross-functional team with skillsets reflecting both areas; and to be successful the business must be represented as well.

These individuals should understand DevOps itself, but also be familiar with the processes and technologies that are needed to make the DevOps implementation successful. They must be completely dedicated to the cause and not distracted by other business. As the team progresses, process experts and tool specialists might also be required. The key thing to remember, particularly if you are using consultants, is not to forget the training or skills transfer.


Streamline processes

One of the major outcomes must be the automation of processes across the business. The starting position should logically be demand intake of all levels. More often, the initial focus is within the development organisation, through to QA/test and operations, including back-out in the case of failure. Before rolling out technology, DevOps teams must work on business and IT process improvements to ensure they have identified the challenges that their work could encounter and plan how to eliminate gremlins. Knowledge of existing business processes is a key skill, as is the ability not just to plan and test for success but also to prepare for process failure both for education and triage.


Budget for talent and technology

Although additional headcount, training programmes and technology will be needed to drive DevOps through the organization, over time the value and automation will change the way teams work and should release headcount back into the pool.

Processes including application delivery, service virtualisation, IT automation and release management integrated directly with your change and management systems with will only be successful with knowledgeable team members taking the reins and leveraging their intellectual knowledge. As a first step you should conduct an internal inventory of tools, identifying the gaps and filling the holes needed to support the DevOps methodology.


Get started with your troublesome applications and services

Rather that starting with a ‘big bang’ approach I recommend that organisations consider piloting or testing DevOps before committing completely. The best way to prove the value of DevOps is to start with an application and/or business service that has been causing problems across production and creating headaches for developers and operations alike as they attempt to remove defects. This sample service/application should demonstrate the value that DevOps can deliver. Once you have the recipe correct, repeat and repeat and this approach will soon attract attention across the organisation.


DevOps is a philosophy to focus the organisation on outcomes needed to support the velocity of change in an innovative world. It is not an answer to every business demand but when used effectively and correctly it can deliver real business innovation.


This article was first published in the Spring 2014 issue of Service Talk which is a benefit of ITSMF UK membership

To find out more about our range of workshops and masterclasses including DevOps visit our events calendar


Tags:  DevOps 

Share |
PermalinkComments (0)

Professional Service Management Framework

PSMF is a practical competency model that defines a professional identity for the service management industry and all those that work within it. Whether you’re an individual service management practitioner or an enterprise organisation, PSMF is a way to improve individual and team service management capabilities and to recognise the full value of the service management contribution.LEARN MORE

Ground Floor South
Burford House
Berks RG12 7WW

Tel: 0118 918 6500

Fax: 0118 969 9749

Contact Us