There’s no doubt about it; we’re in the Age of Agile. We’re kind of late into it, yet, I’m frequently asked how we can ‘agilize our ITSM.’
Why isn’t ITSM agile?
ITSM has taken a beating in the Age of Agile; stood up as a bit of straw man; the slow and bureaucratic nemesis of the new protagonist “agile.”
Add to that a perceived “command and control” moniker.
And while I remain unconvinced that ITSM is solely responsible, as with most things, it resonates because there’s a widely recognized experience where organizations using ITSM are decidedly NOT agile.
ITSM dates back to the early days of computing – with computers surrounded by glass walls and where commoners (aka “The Business”) could only ponder the mysteries that happen inside. Unlike other parts of the organization, “IT” was a brand-new profession and had no pre-technology analog equivalent (i.e., accounting using ledger books).
First order of ITSM business – tame the chaos. Let’s get this thing organized. Structure and control were needed.
With IT under control, businesses’ reliance on technology increased, and IT found itself in the spotlight when things went wrong. The business demanded increased consistency and reliability of IT systems. The answer came from professionalizing IT by defining IT services and agreeing to Service Level expectations to which IT would be held accountable. At the time, “Everyone has customers” was a popular business trend.
So, why isn’t ITSM agile?
In part, because the task was to address:
- Efficiency and effectiveness
- Consistency and repeatability
- Reliability and accessibility
- Structure and control
- Compliance and auditability
These business fundamentals haven’t gone out of style. They’re critical strategic differentiators for organizations that master them. But if not accomplished at the velocity of business, they become a constraint that threatens the organization’s very existence.
Making ITSM agile
One of the fundamentals of “agile thinking” is rapidly detecting and responding appropriately to changes.
There’s a couple of critical elements that I want to highlight.
Let’s start with something obvious: if we are to detect changes – such as changes that may impact the business positively or negatively, things like global markets, customer preferences, emerging technology, changes in the social and political landscape – then we must be LOOKING for them. Agile organizations are on the lookout for changes.
Next is the “rapid” concept. Everyone eventually sees changes, often after it’s too late to act. Agile organizations gear themselves to evaluate all changes for potential impact quickly.
And finally, agile organizations respond to changes quickly in ways favorable to the organization’s mission.
The 50/50 rule
When asked how to agilize ITSM, I recommend staring with my Transition 50/50℠.
For any given practice area in ITSM (Change Management, Incident Management, service reviews, etc.). Whatever the current cycle is, reduce that by 50%. So, if you do quarterly service reviews, start doing bi-monthly service reviews.
I know what you’re thinking, “We don’t have time for more meetings!”
That’s where the second 50 comes in – you’re meeting more often but spend half the time in those meetings.
Increased frequency puts you in a much better position to sense changes rapidly. But frequency alone doesn’t accomplish this shift in focus. A shortened timeframe opens the door for more intentional use of time, focusing on what’s most important. I maintain that looking for micro shifts between what’s currently happening and any changes in circumstances that may be opportunities for agile action is paramount.
For Change Management (those who follow me know my thoughts well), this means a change in both cadence and focus (more changes delegated to value streams, and more focus on overall change performance (not each-and-every change)).
For Incident Management, if you’re not mining your incident data looking for gaps, pain points, and opportunities, then start doing it. If you’re doing it, double the frequency of doing so.
And keep on going through each practice area.
Once you’ve had some practice with Transition 50/50, the next step is to identify the most critical areas to increase agility in ITSM. Most organizations have problematic practices that both IT and the company know full well.
Whatever those practices are, implement Transition 50/50 rule again. Slash the cycle time and meeting time in half again. It starts getting real now because it represents enough change for demanding a new approach.
For example, let’s say you started with an hour-long monthly service desk report. In the first step, you’d have instituted an every-other-week 30-minute review. The next step is a weekly, 15-minute review.
What you’ve essentially done is moved from a formal point-in-time presentation that focuses on the distant past (last quarter, last month) to a standup that’s ‘now-forward’ focused.
This agility demands a shift away from PowerPoint to real-time dashboards. The analysis of data on a dashboard offers opportunities to change course sooner. As with a race car driver: it’s the difference between reviewing a race recording and the dynamic analysis of using real-time race telemetry displayed on the in-car heads-up panel supporting rapid, informed decision-making. Real-time decisions are more favorable to the team’s mission for responding to emerging changes.
Same thing, only different?
But the status quo experience tells us that we’ve been doing it “this way” for a long time, and change is hard.
Absent commitment to become more agile, Transition 50/50 is little more than another management fad that fades into obscurity. The decision to make ITSM more agile requires changes in how we think and act.
It’s also not a matter of good/bad, right/wrong. We need to learn the Art of And – where we keep good things and bring in new beneficial elements. (A and B, not A or B).
For example, in the chart below, we need to keep our foundations and then add the things that will enable us to rapidly detect and respond appropriately to change.
|Keep||And also add|
|Cost Optimization||Value Optimization|
|Work in processes||Work on processes|
Throwing ITSM out the window to achieve agility is like throwing the baby out with the bathwater. We must be both flexible AND stable; planning AND learning.
This is how we agilize ITSM.
If you need help applying Transition 50/50, feel free to reach out.
Welcome to the Age of Agile.
Want more on Agile-Izing ITSM? Check out Part 2!