Agile Transformation in an ITSM Environment

Information Technology Service Management (ITSM) describes the process IT teams use to  manage end-to-end delivery of services to customers in order to align with business objectives and ultimately meet IT goals. In this blog, I will focus on the core services that impact software development and maintenance like— Service Request Management, Knowledge Management, Incident Management, Change Management, and Problem Management.

What is Agile?

Agile is becoming increasingly popular in the Federal sector for many reasons. The iterative approach to software development helps teams deliver value faster to customers and is ultimately more cost efficient as teams release features gradually and are able to pivot at the speed of changing requirements versus spending years developing product in a vacuum which may be out of date by the time deployment comes around. The idea is to produce shorter development cycles and more frequent product releases than traditional waterfall project management. This also enables project teams to react faster to changes in the client environment. The Agile process provides greater opportunity for stakeholder engagement and generally offers predictable costs and schedules and improved product quality.

The case for Agile in an ITSM environment

The main focus of Agile is software development but ITSM covers the gamut of services required to provide and restore IT services to customers. Why bother with Agile transformation in an ITSM environment? Here are four reasons Agile is beneficial for ITSM:

The Agile mindset: While Agile is primarily a software development methodology, the Agile philosophy of incremental change, highly collaborative teams, focus on adapting to changes, and delivering quick value to customers are values that can be applied to IT Services Management.

Service Level Objectives (SLO): ITSM frameworks like Information Technology Infrastructure Library (ITIL) require SLOs to be defined as a means of measuring the performance of the Service Provider. Meeting these goals and metrics is key to the success of the project. Agile can help meet SLOs and deliver services more efficiently. SLOs related to management of the Incidents backlog, quicker delivery of service requests, or management of software changes can benefit from using Agile metrics like cycle time, lead time and velocity provide quantitative means to manage backlog and measure throughput.

The software development angle: Core services of ITSM like Incident Management, Service Request Management, Change Management and Problem Management address break-and-fix issues and modifying IT applications. These modifications ultimately will have an impact on software development. These components of ITSM can benefit from implementing an Agile framework.

Continual Service Improvement (CSI): Finally, CSI is a key component of ITSM to ensure that practitioners implement changes and service improvements efficiently, effectively, and continually. Continuous Improvement is an essential element of Agile. Agile ceremonies like Retrospectives provide the opportunity for teams to reflect on completed iterations and identify actions for improvements going forward.

Agile and ITSM: Compatibility Issues

So, Agile is great for ITSM. Then what is the hold up? Here are a few challenges.

SLOs vs Sprints: The focus of ITSM is to restore services as soon as possible while the goal of Agile is to deliver value. For example, if there is an issue with processing a payment in an application, ITSM SLOs dictate that the priority is to ensure the payment is processed as quickly as possible while the Agile approach would focus on enhancing or fixing the application to prevent the issue in the future. An Agile approach would mean the development of user stories and inclusion in an upcoming Sprint which could be more than two weeks away.

The Classic CRB: When it comes to management and control of changes to service components, ITSM is notoriously risk averse. All changes have to be reviewed and approved by a Change Review Board (CRB) / Change Control Board (CCB). CRBs add bureaucracy and delays to the process that do not gel with the Agile philosophy.

The Documentation Factor: Agile believes working software over documentation. As established above, Incident management competes and wins over software development in ITSM. This means that the software state could change while the user stories are finalized and teams are working on Sprints. Without proper documentation, the system changes made while restoring service could create problems for the development teams.

Best of Both worlds – A Hybrid Approach

Can you successfully implement Agile in an ITSM environment? Yes! Here are our suggestions for a hybrid approach.

Give Incident Management its due: By now, we know that restoring service is critical but Agile sprints prevent a delay to resolution. To embrace both approaches, separate the incident management and software change management processes. Create an IR/Application support team devoted to put out fires and be the first responders. This team can be managed through a Kanban board as opposed to a rigid Sprint cadence. System changes can flow to the development teams thereby leveraging Agile framework with quick Sprints.

Implement a more robust Change Approval process: The main challenge with the Change Review and Approval from an Agile lens is the delay. To overcome some of the issues arising from this process, the following options can be considered.

• Develop guidelines to identify low risk changes that can be pre-approved
• Include CRB members in the Agile ceremonies like Sprint Planning and show and tell meetings where change details and priorities can be discussed, and approvals can be provided
• Use Agile user stories and estimation techniques to provide CRB members with the details to provide fast approvals
• Replace the CRB meeting with something more dynamic like a chat channel. Tools like Teams and Slack can be used to post and review change details

Embrace Sprints in place of elaborate release management: Quick Sprints are a key feature of Agile and offer significant benefits in delivering fast value to customers. Typical Release management in ITSM frameworks like ITIL require multiple steps like – finalize scope, plan release, build, UAT, prepare for release, and then deployment. Instead, embrace the simplicity of continuous Sprints and a fixed cadence. Use Agile estimation techniques to assist with backlog prioritization and planning.

Get Smarter with documentation: As established above, we cannot succeed without documentation, nor can we let it be a hold up. The best way to get around it is to get smarter. Automate the documentation of changes.

• After every release, have the deployment tools update the details in the service desk tools so that the incident responders know about the changes. Ensure that documentation is updated as part of “Definition of Done” for each story
• During incidents, the incident management tools should automatically update the service desk tools, ticketing systems, status pages, and stakeholder communications.
• Use Collaboration tools like Slack, Teams to review changes and publish release notes

Closing the Loop – Implement Continuous Monitoring: All frameworks whether related to ITSM or Agile provide a feedback mechanism to improve processes and facilitate Continuous Process Improvements. Agile Retrospectives after each Sprint offer frequent opportunities to review, fix issues, and make improvements going forward. Retrospectives can be used to assist with building a knowledge repository and assist with knowledge management. They also provide a continuous monitoring feedback loop and integrate with the backlog thereby helping with continuous integration and CSI.

IT Service Management and Agile are different frameworks developed to address different areas and issues of IT services and development. Agile offers a lot of benefits, but the question is whether it can be adapted to an ITSM environment. While both have some common goals, there are challenges that need to be considered as well. The goal of this discussion was to provide a high-level framework to integrate the two to achieve a higher level of service. Each organization is unique and the nature of services offered could be different, but there is value to be gained by implementing a hybrid approach by tailoring the process to the customers goals.

Interested in chatting more about implementing Agile in an ITSM Environment? Shoot me an email and let’s chat!