Ask a DevOps team what they think of IT service management and you may get a polite sigh. To many developers, ITSM still means slow change boards, endless tickets and forms that seem designed to stop them shipping anything.
Ask a service management team about DevOps and you may hear the opposite worry: that speed comes at the cost of stability, and that nobody is quite sure what changed when something breaks.
Both concerns are fair. The good news is that they are not in conflict. Speed and control can work together, as long as service management is shaped around how teams actually deliver.
Why the old approach clashes with DevOps
Traditional service management grew up in a world of large, infrequent releases. A weekly change board made sense when changes were big and risky. It makes far less sense when a team deploys small changes many times a day through an automated pipeline.
Applied rigidly, that older model pushes teams to work around the process. Changes get logged after the fact, or not at all. Service management loses visibility, which is exactly what it was meant to protect.
Shaping service management around delivery
This is where VeriSM is useful. Rather than prescribing a single way of working, it encourages organisations to build a service management approach that fits their own context, drawing on ITIL, DevOps, Agile, Lean and other practices as needed.
In practice, that leads to a few clear principles.
Automate the controls
Instead of asking a board to approve every change, build the checks into the pipeline. Automated testing, peer review and deployment records can give stronger assurance than a meeting ever could, and the evidence is captured automatically.
Match the control to the risk
Not every change needs the same scrutiny. Standard, low-risk changes can be pre-approved and flow straight through. Higher-risk changes still get proper review. Teams move faster on the routine work, and attention goes where it matters.
Share responsibility for running services
In many DevOps teams, the people who build a service also support it. That changes how incidents and problems are handled. Service management practices should support this, for example by routing incidents straight to the owning team and making post-incident reviews a normal, blame-free habit.
Keep visibility without the paperwork
Integrate your delivery tools with your ITSM tool so that changes, deployments and incidents are linked automatically. Everyone can see what changed and when, without anyone filling in a form twice.
Where to start
- Map how changes really flow today, from commit to production, and where service management touches that flow.
- Define your standard changes and agree which can be pre-approved.
- Connect your pipeline and ITSM tool so records are created automatically.
- Agree a small set of shared measures, such as deployment frequency, change failure rate and time to restore service.
When service management is built this way, it stops being something DevOps teams tolerate and becomes something that genuinely helps them. Releases stay fast, services stay reliable, and everyone has the visibility they need.
Trying to make service management work with your DevOps and Agile teams? Book a free scoping call and we will help you find the right balance.
