We live in the digital age, and we can access data ubiquitously and quickly. The internet and the smart phone are key pillars of this age, and customers the main beneficiaries. In fact, Klaus Schwab, the founder and executive chairman of the World Economic Forum, stated back in 2016 that:
The possibilities of billions of people connected by mobile devices, with unprecedented processing power, storage capacity, and access to knowledge, are unlimited.
For service providers today, harnessing this power to deliver services that are responsive to ever-evolving customer needs and resilient in the face of disruptions is critical. And for the last 20 years, the Agile methodology for software development has increasingly become the basis for advancing service management, since the thinking behind it captures the adaptiveness and response to change.
Yet, agile and service management are sometimes at odds, with some people considering it a one-versus-the-other argument. Can agile work together with service management? Yes, and let’s see how.
Origins of agile & ITSM
IT service management (ITSM) doesn’t have a definitive start date, but its origins are intrinsically tied to the period of early, large scale mainframe environments. Here, the operations and support activities involved what we now refer to as ITSM processes and practices, such as:
Consolidated knowledge of service management started in the 1980s, with the UK government creating ITIL®, which was adopted around the world as the de facto best practice framework on the subject.
Microsoft used ITIL as the basis to create its proprietary Microsoft Operations Framework (MOF). Since then other frameworks and standards have continued to expand the horizon of knowledge in this space, including:
On the other hand, the Agile methodology emerged from the collective thinking of 17 software developers in a meeting in Snowbird, Utah in February 2001. This group of independent thinkers, who would adopt the name Agile Alliance, were looking for an alternative to documentation driven, heavyweight software development processes.
The output of their meeting was a manifesto that captured the ideals and values needed for a lightweight approach to software development which was itself an umbrella for different approaches and practices that embraced iterative, feedback focused and customer driven aspects. Such approaches include, among others:
Agile vs ITSM
As software development has taken off, driven by the digital age, some have said that ITSM is no longer useful. They claim that the service management approach is inherently counter to the ideals of agile, especially given that a lot of the practices and processes stem from mainframe thinking where flexibility and responsiveness to customer needs was difficult.
Additionally, some have categorized agile as a development concept, and boxed ITSM squarely in operations. This has invariably led to a perception that the two worlds cannot mix. Since Agile espouses methods that are adaptive and people-oriented rather than predictive and process oriented, then the thinking has been that this is counter to ITSM which adopts a more process-centric approach.
However, the reality is that agile and ITSM have a lot of synergies. Putting the two together can go a long way in in providing value to the enterprise.
Agile & ITSM together
While ITSM originated from a more structured process approach, there is nothing that says that its practices cannot borrow from agile thinking and improve the delivery of value to customers through speed, experimentation, and iteration in service management.
The development in digital technology means that old process approaches have to be adjusted to conform to the digital age. More recent versions of ITSM approaches, like ITIL 4 and VeriSM, are aligned to this mindset.
Let’s walk through the Agile Manifesto and see how this thinking can be applied to service management.
We value individuals and interactions over processes and tools
In ITSM, let’s say we have an incident that was reported by a customer and logged on an ITSM ticketing tool. It’s not clear what the cause is. Here, there is a risk that a rigid workflow would see the issue bounce around different siloed teams looking for a resolution, which would:
- Cause delays
- Impact customer satisfaction
A different approach would be to adopt a technique such as swarming that brings different teams to a common ground to work together to find a solution, thus going outside the tool workflow. That means that teams would:
- Not require bureaucratic channels to communicate.
- Use common systems that allow unhindered information flow.
The same thinking can apply to IT projects where information is shared across different teams openly, and forums are available for people of different skillsets to share knowledge and work together, encouraged by fluid organizational structures that do not hamper collaboration. This could lead to shared workspaces where ITSM practitioners can sit and work together, regardless of individual specialty.
We value working software over comprehensive documentation
When planning for a change, ITSM practitioners are sticklers for volumes of documentation to try to mitigate risk in case of a potential service outage or degradation. Sometimes even simple changes are taken through rigorous change evaluations and protracted CAB meetings. But when it comes to meeting customer needs, agile thinking prefers quickly executing changes that generate value.
To get a balance, ITSM practitioners will need to graduate to a thinking of efficiently processing different change types, such as:
- Referencing sprint backlogs for information instead of requiring documents attached to change requests
- Adopting peer review techniques and CI/CD technologies in change reviews and execution, respectively
These capabilities enhance speed in delivery of new and improved service features—which is more appreciated than the amount of supporting documentation.
The same thinking applies to how you treat incidents and problems in the ITSM environment. Instead of insisting on detailed documents regarding the chosen remedial actions, you could embrace a more experimental approach to improvements, where you would:
- Adopt iterative actions with immediate review and feedback.
- Then build the supporting documentation after addressing the issues.
We value customer collaboration over contract negotiation
The customer is king, and in ITSM, whether it is an internal user or external customer, the focus must change to value for them. Instead of rigid service level agreements (SLAs) that see service providers do everything to meet them, at the expense of the customer, a more collaborative approach of partnering with users and partners in all aspects of service management is adopted.
Here’s an example of collaboration over negotiation: Rather than maintaining static agreements and plans that do not consider the evolving environment, you could regularly consult business users to find out their priorities and preferences and adjust accordingly.
ITSM practitioners can build on existing business relationship management (BRM) practices to ensure that their service delivery model (including services and processes) is developed with stakeholder input rather than independent of them.
(See how agile, ITSM & BRM collectively support the business.)
We value responding to change over following a plan
As mentioned earlier, an agile approach will change if customer feedback requires it, or when the team realizes that there are better opportunities in creating more value.
ITSM practitioners can borrow from this thinking by embracing a more flexible approach to service management. For instance, by collaborating with the business, you can:
- Release new features earlier than planned
- Review and reprioritize scheduled improvements in response to changes in the business
Adopting flexible service infrastructure, especially through cloud environments, can also facilitate this mode of working as responsiveness is enhanced and rigidity is nullified. Change schedules should also not be set in stone as provisions should be made in case different positions are taken by relevant stakeholders.
Service management can be agile
It’s clear that we need to stop boxing agile into a development-only concept that only part of IT can use. As agility continues to spread across the whole business, not just the IT organization, service management can certainly harness agile thinking to enhance service delivery and improve customer service.
