{"id":34143,"date":"2023-02-16T10:57:07","date_gmt":"2023-02-16T10:57:07","guid":{"rendered":"https:\/\/digileaders.com\/?p=34143"},"modified":"2023-02-16T10:57:31","modified_gmt":"2023-02-16T10:57:31","slug":"bridging-the-gap-between-itsm-and-agile","status":"publish","type":"post","link":"https:\/\/digileaders.com\/bridging-the-gap-between-itsm-and-agile\/","title":{"rendered":"Bridging the gap between ITSM and agile"},"content":{"rendered":"

There\u2019s a million methodologies that can be used to deliver software. The set of tools you choose will vary depending on the problem you\u2019re trying to solve. And occasionally you\u2019ll\u00a0blend different approaches<\/a>\u00a0to find the process that\u2019s just right for you and your team.<\/p>\n

But every now and then you\u2019ll hit a wall and might be tempted to say \u201cit just can\u2019t be done\u201d. Many delivery managers and clients will say that blending Information Technology Service Management (ITSM) and agile is one of those examples, but I\u2019m here to tell you that\u2019s not true! Don\u2019t believe what you\u2019ve been told, you\u00a0can<\/em>\u00a0have it all.<\/p>\n

First, let\u2019s make sure we\u2019re all on the same page. What do I mean when I say ITSM and agile?<\/p>\n

 <\/p>\n

ITSM<\/h3>\n

ITSM = Information Technology Service Management.\u00a0<\/em><\/p>\n

ITSM is a set of activities and processes that organisations use to manage the services they offer to users. ITSM is also a profession filled with experts and specialists in multiple ITSM processes.<\/p>\n

We see ITSM most commonly in production application support: live services that need to be maintained so users get continuity and quality services.<\/p>\n

 <\/p>\n

Agile<\/h3>\n

Agile is an umbrella term that applies to many methodologies, all of which are based on and refer back to the\u00a0Agile Manifesto<\/a>:<\/p>\n

individuals and interactions\u00a0><\/strong>\u00a0processes and tools<\/p>\n

working software\u00a0><\/strong>\u00a0comprehensive documentation<\/p>\n

customer collaboration\u00a0><\/strong>\u00a0contract negotiation<\/p>\n

responding to change\u00a0><\/strong>\u00a0following a plan<\/p>\n

Agile supports rapid input from users and stakeholders as well as an early return on investment.<\/p>\n

 <\/p>\n

The conflict<\/h3>\n

The conflict between ITSM and agile lies in how each measures success.<\/p>\n

Core to ITSM is the measure of Service Level Agreements (SLAs) which include targets around response time and uptime. These SLAs are contracted for, measured strictly and often result in penalties if they\u2019re not met. This approach doesn\u2019t align well with the Agile Manifesto that customer collaboration comes over contract negotiation.<\/p>\n

ITSM also follows a strict set of processes. These include things like using tiers of support \u2013 where service desk responders receive and categorise issues which are then handed over to a resolver group, who may then hand it over to another resolver group or engineering team, who even then may hand it over to an external party. These handovers are strictly defined and the bounds of responsibility for each group are inflexible, leaving little room for collaboration. These processes and tools are the priority rather than the individuals and interactions we focus on when following the Agile Manifesto.<\/p>\n

 <\/p>\n

An alternative<\/h3>\n

It\u2019s important to note here that the conflicts with ITSM and agile that seem overwhelming are not conflicts with ITSM at all. They\u2019re conflicts with how ITSM is\u00a0traditionally<\/em>\u00a0implemented. The good news is, things don\u2019t have to be this way.<\/p>\n

By implementing a swarmed ITSM approach, services can be supported by smaller teams of specialists that embed agile ways of working without compromising on the quality of the service.<\/p>\n

A swarm model removes the strict rules between tiers and instead groups the expertise of responders in tier 1, the resolvers in tier 2 and engineers in tier 3. The team can then introduce an agile approach that works for them.<\/p>\n

It\u2019s at this point they can agree success measures with their client that prioritises user needs and user experience over response time. The great thing is that these teams can also be flexible to include skills you don\u2019t typically see in production application support, such as user research and business analysis. And wonderful news \u2013 this helps you embed continuous improvement into your service on top of the ongoing maintenance expectations you already have.<\/p>\n

This alternative approach allows you to get the best of ITSM (continuity and quality of service) while also getting the best of agile (user focus and rapid return on investment).<\/p>\n

 <\/p>\n

Tried and tested<\/h3>\n

\u201cThat all sounds great in theory, but it isn\u2019t all that practical\u201d<\/em>\u00a0I hear you say. Well we practise what we preach here at Made Tech and have been using this swarm approach with a number of clients.<\/p>\n

One example is a team of engineers, analysts and researchers supporting a critical application on behalf of a government department. This support model has no distinction between level 2 and level 3 team members, and uses a swarm approach to resolve issues and incidents. The team has demonstrated that rigid ownership and guidelines are not needed to provide quality incident management. And bonus \u2013 their swarms are now joined by other suppliers who\u2019ve been convinced of the benefits!<\/p>\n

By using a swarm approach the team have made sure that this critical service has had 100% availability (excluding planned maintenance) and that all user impacting incidents have been fully resolved, not just responded to, within 48 hours. They\u2019ve deployed improvements to the service that automate common service requests, cutting the cost of supporting the service by over 75% when compared with the previous supplier.<\/p>\n

 <\/p>\n

A tiered approach may be right sometimes<\/h3>\n

Having said all that, a tiered approach may still be the right approach for your organisation. It\u2019s not one size fits all. For example:<\/p>\n