Agile incident management is a term that is yet to have any satisfactory hits on the Internet, as organizations are still pretty skeptical about using agile methodologies to manage incidents occurring in IT organizations. The most common approach is ITSM, followed by COBIT and ISO standards.
Integration of Agile
However, the adoption rate of agile methodologies has shown an upward scaling since its inception 15 years ago. The following chart is based on the State of Performance Engineering 2015-16, an online HP survey where 601 IT professionals participated. The rate of agile adoption seems quite encouraging based on the results.
What Is Incident Management?
Incidents could be the unpredicted disruptions in a standard IT workflow or the dropping quality range of an IT service. If a service functionality is unable to show results, it can also be accounted as an incident. There is a source behind every incident.
Incident management is a set of activities that deals with the following areas in its lifecycle:
- Investigating the source of disruptions in an IT lifecycle
- Making corrective measures to normalize problems in services and operations
- Taking necessary actions to reduce incident repetition
- Closing an issue after implementing root cause analysis (RCA)
Why Is Incident Management Important?
Since incident management has a higher visibility rate in a business, it is addressed primarily in service management and is comparatively easier to establish its value in service operation. For this reason, incident management can be used to focus on other fields in need of dire attention.
In its lifecycle, an incident needs to be tracked regularly as a part of recovery procedure, and clients need to be updated about the stage the incident has reached in the management lifecycle.
How Different Is Agile Incident Management from That of ITIL’s?
Incorporating agile methodologies in managing incidents allows for automation of lifecycle progress and lowered escalation rate in the organization. An agile incident management system has some recognizable characteristics—lifecycle management, data collection, association, description, and adaptability. Whereas an ITIL approach to incident management consists of a variety of steps that include inputs, identification, logging, classification, prioritization, initial diagnosis, escalation, investigation and diagnosis, resolution, and closure. Though ITIL is a set of best practices for ITSM, some definitions are debatable. According to ITIL, incidents are not something that disrupts business. Then why is there such an elaborate procedure to fix it?
A comparative study in the following chart reveals the differences between the ITIL and agile frameworks.
Other Approaches to Incident Management
There are other frameworks that are used for incident management:
COBIT: Control Objectives for Information and Related Technologies has six steps for incident management.
ISO: International Organization for Standardization (ISO) has five stages.
How ITIL Can Also Be Agile Incident Management
ITIL, being the most practiced framework in the world, can incorporate agile methodologies for a modern approach to incident management. In fact, a lot of ITIL processes support agile values more than agile frameworks, but are not practiced because of the resistance to change. Going through hundreds of pages of documents during emergencies actually lengthens the management process and might need more manpower than necessary. By applying four set of agile principles into the plan, agile incident management would give the best results.
Instead of sketching a plan for the whole process and sticking to it, the plan can be made in bits and pieces and be added as and when required. The actions will not be blocked, and they will be open to further division into sections and undertakings not foreseen before. When the undertakings are clearer, the related actionable items, resource acquisition, and required facility lists along with response teams based on operational needs can be created. The plan can go on until the need is fulfilled, and the process can move to the next iterative cycle.
Open to Changing Environment
A plan can be formulated when the future is predictable, but for incidents there are always deviations. The best possible way to address an incident is to have a flexible methodology that supports situational updates. When feedback is received, agile teams use it to implement a better strategy. These help to cope with the changing environment and incoming demands.
According to Sam Guckenheimer, by using the value-up approach rather than the work-down method, progress in the management process will be measured based on the values a cycle produced and not on the quantity of tasks completed. To make this possible, the undertakings should be simple enough to be delivered in a short span, be able to be worked out independently, and add value that would lead the team closer to the intended goal.
Planning should be done taking into view all the stakeholder opinions and team member participation in the process. Meetings cannot be decided beforehand, and this holds true for detailed plans too. The plan can be modified incrementally by frequent discussions with all the parties so that everyone feels involved and responsible for value addition. Usually, stakeholders are last in line to know about progress and feel left out or detached from the plan. This sense of vested accountability and open forum will allow them to focus more on the ongoing project.
A part of the collaborative effort, having direct conversation regularly within teams is more important than meetings. Meetings are still considered a formal forum, and reading through all the documents may be problematic. Instead, having a face-to-face talk clarifies doubts and solves a problem faster and more effectively. Availability of knowledge transfer will allow team members to find out the deviation needed and implement the changes quicker.
It is only when the model is working that the team is nearing its goal. No amount of detailed documentation, long working hours, tons of spent money, or the finished process cycles will bring any value if the result in the end amounts to zero. If a plan was made in the initial stage, the effectiveness of the plan is the actual parameter to understand effectiveness. Calculating values is more important in agile incident management.
Incidents come without prior notification, so having a plan for something that is not even in view is kind of a digression. However, adopting changes to stop repetition of such incidents is more possible. All the organization has to do is be more prepared to be agile. Every issue cannot be solved by agile because it is mostly used for software development. However, if the benefits are more than the issues faced in the incident lifecycle, agile incident management should be the talk of the town.