There’s a million methodologies that can be used to deliver software. The set of tools you choose will vary depending on the problem you’re trying to solve. And occasionally you’ll blend different approaches to find the process that’s just right for you and your team.
But every now and then you’ll hit a wall and might be tempted to say “it just can’t be done”. Many delivery managers and clients will say that blending Information Technology Service Management (ITSM) and agile is one of those examples, but I’m here to tell you that’s not true! Don’t believe what you’ve been told, you can have it all.
First, let’s make sure we’re all on the same page. What do I mean when I say ITSM and agile?
ITSM
ITSM = Information Technology Service Management.
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.
We see ITSM most commonly in production application support: live services that need to be maintained so users get continuity and quality services.
Agile
Agile is an umbrella term that applies to many methodologies, all of which are based on and refer back to the Agile Manifesto:
individuals and interactions > processes and tools
working software > comprehensive documentation
customer collaboration > contract negotiation
responding to change > following a plan
Agile supports rapid input from users and stakeholders as well as an early return on investment.
The conflict
The conflict between ITSM and agile lies in how each measures success.
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’re not met. This approach doesn’t align well with the Agile Manifesto that customer collaboration comes over contract negotiation.
ITSM also follows a strict set of processes. These include things like using tiers of support – 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.
An alternative
It’s important to note here that the conflicts with ITSM and agile that seem overwhelming are not conflicts with ITSM at all. They’re conflicts with how ITSM is traditionally implemented. The good news is, things don’t have to be this way.
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.
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.
It’s 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’t typically see in production application support, such as user research and business analysis. And wonderful news – this helps you embed continuous improvement into your service on top of the ongoing maintenance expectations you already have.
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).
Tried and tested
“That all sounds great in theory, but it isn’t all that practical” I 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.
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 – their swarms are now joined by other suppliers who’ve been convinced of the benefits!
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’ve 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.
A tiered approach may be right sometimes
Having said all that, a tiered approach may still be the right approach for your organisation. It’s not one size fits all. For example:
- if you’re supporting 50 products each with 5,000 users, then it helps to have a tier 1 who can receive issues, screen them for importance and make sure it’s sent to the right people to fix. You can then set up a two tier approach that passes issues down to resolve.
- if you’re an organisation that outsources its IT services and has a multi-supplier environment then a traditional tiered model could be your friend as it helps balance service management with supplier management.
We recognise that traditional ITSM processes have their value, but shouldn’t be the default. Increasing efficiency through this alternative approach allows public funds to be focused on improving services rather than simply “keeping the lights on” and will ultimately help us reduce the build up of legacy technology.
If you’d like more Made Tech content delivered straight to your inbox, sign up for our monthy Insights newsletter.
.png){kind=logo}
.jpg){kind=spacer}
