Agile ITSM – the term has been discussed for a few years now so surely you’ve encountered it somewhere along the way.  But do you understand what it is and what it means to an organization?  I bet there are quite a number of organizations who would tell you that they are doing agile ITSM, but are they really?

What is Agile?

The definition of agile is being quick and responsive to changes around you.  Agile is not something that you can wake up one day and say you’re agile.  Being Agile in IT is more of a mindset change than necessarily a process change.  Being truly agile needs practice and a new way of thinking about the tasks that have been requested.

A lot of people automatically think Scrum or Kanban when they hear the term agile.  These tools for project management are certainly used in the organizations that are following an agile process, but that’s really what they are – just project management tools. They do not define the process as agile.

Agile was introduced in 2001 with the Manifesto for Agile Software Development (www.agilemanifesto.org), which simply states:

“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.”

Note that the authors didn’t define HOW to do agile, just WHAT being agile is.  While their intent was initially focused on software development, these same principles can be applied to the fulfillment of many other business related requests as well.

As Jayne Gordon Groll states in her excellent document “The Agile Service Management Guide” (http://www.itsmacademy.com/content/Agile%20Service%20Management%20Guide%20V1%20031715.pdf)

The Agile Manifesto is underpinned by twelve principles of Agile software

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face‐to‐face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity‐‐the art of maximizing the amount of work not done‐‐is essential.
  11. The best architectures, requirements, and designs emerge from self‐organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

These principles are not significantly different than the principles that underpin service management

  • Be aligned with the business  
  • Focus on customer outcomes
  • Ensure ongoing customer value
  • Understand and enable business success
  • Deliver quality IT services
  • Restore service as quickly as possible
  • Adapt to changing requirements
  • Minimize risks
  • Be effective and efficient
  • Make processes sustainable and repeatable
  • Fulfill IT governance requirements

There is clearly alignment between the objectives of the Agile Manifesto and the objectives of service management.  Unfortunately, that alignment does not necessarily translate into end‐to‐end agility.     IT must now learn to be agile throughout the entire service lifecycle ‐ from concept to retirement.

What is Agile ITSM?

Is there an IT shop that has all the resources that are required to implement everything the business asks of it?  Every shop that I have come into contact with is asked to do more with less, year after year.  With this in mind, it makes sense for IT to focus on the most critical business items first, implementing them in as rapid a manner as possible.  The service management team is no different in this respect and they need to find ways to meet the business needs with the resources they have available.

While researching this article I kept asking myself, how can the ITSM team put agile into practice?  What does that mean for them on a daily basis?

For example, should the problem management team use a process of only assigning a single problem to an individual so that they can focus on that one incident?  Keeping the rest of the problems in a “backlog”? Is that appreciably different than what they are doing today? It might be, especially from the individual’s viewpoint.  They have just one problem to focus all of their efforts on.  Delivering a resolution as quickly as possible in line with the business requirements for that one problem. Some individuals are more efficient with time management using this approach.  Other individuals like to have a few problems assigned to them so that when they are “blocked” on making progress on one problem, they can begin working on the next problem in their queue. Either means of assignment works, but does one define being agile more than the other?

Or should the change management process be modified to allow changes to happen as quickly as possible?  I would not promote completely doing away with the change management process since it provides a healthy balance between random changes to the production environment and the stability of business services that is required by the organization. IT customers are always going to be reliant on these services, so the services will always need to be managed to some extent.  However, I think it is important to review the change management processes that are in place to make sure that all steps are being accomplished in the most expeditious means possible for the organization.

The primary benefit of being agile in ITSM is when the service management team looks at the processes that are in place or at new processes that are being requested by the business. For the processes that are currently in place, are there incremental improvements that can be made to either bring them more in line with business objectives or to improve the agility of the process.

An example of this might be a service request that results in provisioning a new AWS instance.  If this process currently requires manual interaction to fulfill the service request, this process could be automated to reduce the time it takes to complete the request.

Another example is a process that currently requires multiple approvals and takes weeks to complete.  If the business requirements change, this process could be updated reducing the time to completion.

I think that the easiest application of agile is when new processes are being requested by the business.  The rate at which the business changes are happening is rapidly increasing, so it follows that the time to implement new business process requirements is also rapidly increasing in order to meet these business changes.  The implementation of this process should follow agile principles and could even follow a Scrum or Kanban style of project management in order to implement the process.  By applying agile principles:

  • Implementing in small, frequent increments
  • Collaborating with business owners to make certain that each increment is in line with the business requirements
  • Receiving feedback to influence future incremental changes

The process will deliver the value to the business quicker and with greater adherence to the business needs.

Conclusion

What is Agile ITSM?  I think there are two parts to it:

  • Looking closely at the processes that are currently in place to see if there are incremental improvements that can be made to speed them up. This sounds very much like the ITIL concept of Continual Service Improvement.
  • Using Scrum or Kanban project management practices to implement new process requests. This may be implementing something like a new process for problem management or even new service catalog entries and the fulfillment process associated with them.

Further References:

http://www.theitsmreview.com/2013/08/applying-agile/

http://www.itsmacademy.com/content/Agile%20Service%20Management%20Guide%20V1%20031715.pdf

http://www.joetheitguy.com/2015/04/30/getting-started-with-agile-itsm/

http://www.mynewsdesk.com/se/3gamma/blog_posts/the-state-of-itsm-in-agile-organizations-delivering-agile-innovation-while-supporting-stable-it-operations-38380

https://www.linkedin.com/pulse/agile-mind-set-its-application-service-management-dolf-van-der-haven