Start your ITSM improvement journey now (with a little help from your friends at AXELOS)

2656648042_0ced853512_z

Yesterday, AXELOS launched a brand new competition aimed at helping IT professionals kick-start and/or revive their ITSM initiatives.

With the help of independent, industry experts, AXELOS will be providing entrants with a list of tasks, along with practical guidance on how to successfully complete them in order to start people out on their journey of ITSM improvement.

The purpose

AXELOS’s objective with this competition is to show how ITSM improvement initiatives can be agile, iterative, and business focused, and that CSI is an integral part of all processes and activities. There is no need for a huge 2-year-long project plan to kick things off – a few enthusiastic people with proper guidance can achieve a lot! The outcomes from this competition will serve as the basis for each participating organization to create their own prioritized list of improvements – a proper CSI register. The prizes that AXELOS has selected for the most impressive ITIL journeys will help to engage the whole organization at the next level, and to build the momentum.

The competition

The competition, otherwise known as the “ITIL Journey”, will be divided into three 2-week sprints, each of which will have a specific focus. In order to participate you will need to download the AXELOS foldable prism.

The sprint topics will be:

  • Sprint 1 – Listening and Engagement – May 12th – May 25th 2014
  • Sprint 2 – Quantifying and Reviewing – May 27th – June 8th 2014
  • Sprint 3 – Prioritizing and Planning – June 9th – June 22nd 2014

Each set of tasks for individual sprints focuses on the theme of the sprint and builds on the previous sprints. The tasks for each sprint will be revealed in the beginning of that sprint.

By the end of the competition, when all three sprints are completed, you will have a prioritized list of improvements that is based on actual data and business requirements, rather than just on hard-to-prove gut feeling. You will also have shown, by completing a few low hanging fruit improvement tasks, that the initiative does bring value – and this helps to build a momentum in your organization. All tasks from previous sprints will be available in an ordered ‘backlog’ – this way, you can include them in your sprints along the way.

The competition is not UK-only-based and you can take part from anywhere in the world. All you need to do to enter is submit a photo of your completed prism along with any documentation that you have created to AXELOS by 30th June 2014.

You don’t have to have been involved from the start to join in either. You can essentially even join in the third sprint, you will just complete less tasks. For maximum value to your organization and for the best chance to win the competition, we highly recommend that you start your ITIL Journey now (or at least as soon as possible).

The prize

The three best submissions will receive a voucher for a full-day in-house ITIL simulation game from one of the following Accredited Training Organizations (ATOs): G2G3, Gamingworks and Simagine.

In a nutshell

  • Find out how to engage with your customers and understand their needs
  • Review and evaluate your current processes and metrics
  • Identify quick wins to address first and get buy-in from stakeholders
  • Map your activities to value your customers expect
  • Make use of free-of-charge insights and guidance from industry experts
  • Win a full-day ITIL simulation for your organization

For more information about the ITIL Journey competition, including how to take part and submit please visit the website.

Image Credit

Agile CSI: continual service improvement done right

10034579444_60a0fdc982_zDon’t worry. I am not going to rant on about hypothetical methods or visionary statements. I will not explain why agile is important for the ITSM industry, nor will I explain why agility is crucial for business survival. After all, these are no-brainers, right? I will only use your valuable time to illustrate a practical experience on implementing continual service improvement (CSI), the agile way.

In the past few years I have been privileged to apply lean and agile principles, methods and instruments to many different (IT) service environments. Most of the assignments were focused on delivering more value to stakeholders, improving collaboration between functions and domains, and reducing change lead times. However, one of the most intriguing assignments revolved around creating a culture of continuous improvement for a professional services company.

The problem

First, here’s some context. The customer I am referring to, is in the business of providing professional infrastructure and telecom services to its customers. The IT director realized they had a huge problem, when their largest customer repeatedly complained about their supplier’s reactive behavior. Surely, the customer got what they asked for, but there was no such thing as proactive service management, let alone continuous improvement of processes and services. My customer thought that they had this covered by having an extensive description of a CSI process, according to ITILv3. Yet somehow, no real improvements were initiated, let alone carried out. I profoundly assume this does not surprise you.

ITIL

Looking at the core objective of CSI, I have always applauded this addition to the ITIL set. After all, it recognized the essence of having a flying wheel for improvements throughout the IT service organization and lifecycle. However, allocating a separate process and rather waterfall and administrative approach to achieving this objective, is why ITIL’s CSI falls short in so many implementation attempts. Similar to Imai’s Gemba Kaizen, successful continuous improvement in IT services involves small, bottom-up, incremental improvements, integrated in business as usual. In addition, ITIL fails to address the most important element of achieving continuous improvement: culture. For instance, as long as the culture of the organization does not reward improvements or even does not allow mistakes to be made, those mistakes/errors will be covered up, instead of being visualized, improved and learned from.

Agile

This is where the Agile way of thinking comes in. At this organization, we introduced agile principles (eg. multidisciplinary, self-organized teams), methods (scrum) and instruments (kanban) to address their improvement issues, and to grow towards a proactive service organization. We started off with scrum. First by ensuring all stakeholders had a shared understanding of agile principles, the scrum process and its relevance to support and operational environments. After that, we allocated the roles. The complaining customer picked up the product owner role, whereas the service manager became the scrum master. The primary people involved in the service chain (service desk, design, develop, test, operations, main supplier) were involved as team members.

Then, as a joint effort, the entire team investigated the current opportunities for improvements, both on processes and delivered services. All improvements were collected on a product backlog (i.e. an improvement backlog). We used a uniform format to write them down: user stories. The good thing about user stories, is that they are short and simple, yet always address the “why” question. This resulted in user stories such as below:

agile

In parallel, we used planning poker as an instrument to estimate the improvements. I find this a particularly useful way of estimating both changes and improvements. The relative measure (story points) appeals to the unpredictive and indeterministic nature of so many changes and improvements.

In two weeks time, we had the product backlog filled (i.e. “ready” for 3 sprints), and prioritized by the product owner. So yes, this means that the customer decided where improvements were to be made first. After that, we narrowed down the product backlog into a sprint backlog for the first sprint and started off with a planning session for that sprint. Here, we created tasks for the allocated user stories, which were added to the physical scrum board we had set up. Together with the other, obvious ceremonies (stand up, demo, retrospective), the scrum process was in place and led by the service manager (scrum master). Every day, the team members pulled their actions through the process, picked up and realized the improvements during the 3 sprints.

Results

After three sprints of each one month, 80% of all identified improvements had been realized. And implemented. Result: an engaged customer, visibly happy with the improvements made thus far and confident regarding the proactive capabilities of the service organization. But it didn’t stop there. Yes, we stopped using scrum. After three sprints the backlog almost evaporated. But at that time, it was still positioned as a separate instrument. That is why we incorporated all future improvements on the regular kanban board, which was already used for incidents, problems and changes. Improvements became business as usual. All team members, including the customer, were actively involved throughout the delivery chain, all aimed at continuously improving the service delivery chain. The people involved were all aware of the priorities of their work in progress, and the value of their daily improvements.

I hear you say: this sounds too good to be true. Of course, we encountered several problems along the way. Quite a few team members were skeptical with regard to using agile principles and instruments. Showing them the value of visualization, sharing tasks across the multidisciplinary team and providing insight into the entire delivery chain, really catalyzed their changing attitudes. In addition, it was certainly not easy keeping everyone on track and on focus for the improvements during the sprints, next to their daily incidents, project work and other engagements. Daily stand-ups, management attention and visualizing results have surely contributed here.

The future

Creating a continuous improvement mindset is all about stimulating a learning culture. You are never ready. The same goes here. Having a CSI mindset is not enough to keep learning effectively. Further improvements for this organization include the optimization of measurements, and a further integration of Lean and Agile elements, or from Rob England’s TIPU framework.

Agile CSI is only one example of how agile and lean principles and instruments can help the IT function deliver great services. ITSM has a key role in achieving this, by sharing practical experiences, good practices, but most of all creating the conditions for all stakeholders to improve their work, processes and services.

Want to hear more from me on this topic? Join my BrightTalk webinar on 10th September 2014.

Image Credit