ITIL 4 gives IT organizations a common language for value, risk, and governance. Agile and lean practices give them speed. The two camps argue endlessly about which one wins, when the real question — the one that shows up on a maturity assessment — is how well you’ve wired them together.
Why This Debate Won’t Die
Every few years someone declares ITIL “dead” and agile “the future,” or the reverse. Neither is true, and the framing itself is lazy. ITIL 4 was rebuilt specifically to absorb agile, Lean, and DevOps thinking rather than compete with it — the Service Value System was AXELOS’s answer to years of complaints that ITIL v3’s lifecycle model was too linear and too slow for organizations shipping code weekly. As of February 2026, PeopleCert pushed that evolution further with ITIL Version 5, described in its own release notes as roughly 40% carried over from ITIL 4, 36% new material, and 24% revised — a signal that the framework itself keeps absorbing feedback rather than standing still.
Meanwhile, plenty of engineering teams run incident response through Slack and PagerDuty and never open a formal service management tool until someone needs a compliance record. Both worlds are real. Both produce results. The friction comes from treating them as mutually exclusive philosophies instead of two toolkits solving different parts of the same problem.
Adoption data backs up the “blended, not binary” reality. In an ITSM.tools industry survey, roughly 20% of organizations reported they had already adopted or were actively adopting ITIL 4, with another 32.5% planning to adopt parts of it. Awareness was near-universal (98.1% had at least heard of ITIL 4), but full-framework adoption was always the minority path. Most shops cherry-pick the practices that solve a problem they actually have and leave the rest on the shelf.
What ITIL 4 Actually Brings to the Table
The Service Value System, in plain terms
The Service Value System is the umbrella: guiding principles, governance, the service value chain, practices, and continual improvement, all feeding into value creation for stakeholders. It replaced the old five-stage lifecycle (Strategy, Design, Transition, Operation, CSI) with something looser — six activities in the service value chain (plan, improve, engage, design and transition, obtain/build, deliver and support) that organizations combine into whatever value streams fit their actual work. That’s a meaningfully different design than v3. It was built to flex.
The seven guiding principles — focus on value, start where you are, progress iteratively with feedback, collaborate and promote visibility, think holistically, keep it simple and practical, optimize and automate — read almost like an agile manifesto with a British accent. “Progress iteratively with feedback” is basically a sprint cadence in ITIL vocabulary. “Start where you are” is the entire premise behind not ripping out working systems just because a framework says so.
34 practices, not 34 silos
The practice model (34 practices across general management, service management, and technical management) trips people up because it looks like 34 separate processes to document and audit. That’s the wrong reading. Incident management, problem management, change enablement, and release management are meant to be assembled into value streams on demand, not run as isolated departments handing off tickets. Change enablement in ITIL 4, for instance, explicitly distinguishes standard, normal, and emergency changes — and standard changes are supposed to be pre-approved and low-friction, which is the exact mechanism that lets CI/CD pipelines push dozens of changes a day without a CAB meeting for every one. The framework already has a lane for velocity. Most organizations just never configure it that way.
Where Agile and Lean ITSM Push Back
Kanban replacing the ticket queue
Traditional service desks measure tickets by SLA countdown. Kanban-based ITSM measures flow — work-in-progress limits, cycle time, and blockers made visible on a board instead of buried in a queue sorted by priority flag. The practical difference matters: a WIP-limited board forces a team to finish work before starting more, which surfaces bottlenecks a priority-sorted queue hides. Teams that move service desk operations to Kanban commonly report shorter cycle times and clearer bottleneck visibility, because the board makes queueing delay visible in a way an SLA countdown timer never does.
Sprint-based problem management
ITIL’s problem management practice includes a continual improvement register almost by design, but it doesn’t mandate a cadence. Agile-influenced teams borrow the sprint structure anyway: root-cause analysis, known-error database entries, and permanent fixes get pulled into two-week increments with a backlog, a demo, and a retro. It’s the same practice ITIL describes, run with sprint mechanics bolted on. Nothing in ITIL 4 forbids this — the guiding principle “progress iteratively with feedback” argues for it directly — but plenty of ITIL implementations never get there because problem management sits in someone’s backlog behind incident firefighting.
DevOps-influenced incident response
This is where the philosophical gap is real, not imagined. DevOps and SRE-influenced incident response treats an incident as an engineering event: an on-call engineer gets paged, works the problem in a chat channel with the people who wrote the code, and closes it out with a blameless postmortem. ITIL’s incident management practice, run traditionally, treats an incident as a service event: log it, categorize it, assign it, track time-to-resolve against an SLA, close it with a satisfaction survey. Both are legitimate. They just optimize for different things — one for engineering speed and root-cause learning, the other for accountability and service continuity across a multi-vendor estate.
Where They Actually Collide
The honest conflict points are narrower than the discourse suggests, but they’re real:
Change approval speed is the biggest one. A CAB that meets weekly can’t keep pace with a team deploying to production ten times a day. If every deployment routes through the same approval path as a data-center migration, agility dies on the vine.
Documentation overhead is the second. Agile teams resist writing detailed change records and CMDB updates for every pull request; ITIL-oriented governance wants the audit trail intact for compliance and problem management to work later. Skip it and your six-months-later root-cause analysis has nothing to work from.
Ownership models clash too. DevOps assumes “you build it, you run it” — the same team owns code and operations. Classic ITSM assumes a service desk, a set of resolver groups, and formal handoffs between them. Merge the two badly and you get engineers who won’t touch the ticketing system and service desk staff who can’t page the team that actually owns the failing component.
There’s a fourth collision that shows up specifically in larger, multi-vendor environments: who owns the process when five different suppliers each run their own flavor of agile delivery. This is exactly the gap Service Integration and Management (SIAM) was built to close — a layer that sits above individual supplier practices and coordinates them against one shared service model. Organizations running SIAM alongside ITIL 4 tend to treat the two as complementary rather than competing: ITIL supplies the practice vocabulary and governance structure, SIAM supplies the cross-supplier coordination, and each supplier is free to run Scrum, Kanban, or whatever delivery method suits its own team underneath.
Where They Reinforce Each Other
The overlap is bigger than the conflict, though, and it’s worth naming directly. Continual improvement — ITIL’s dedicated value chain activity — is Lean’s kaizen loop with different terminology. Shift-left practices in DevOps (catching defects earlier, embedding quality checks in the pipeline) map cleanly onto ITIL’s “optimize and automate” principle. Blameless postmortems and ITIL’s problem management both exist to stop the same failure from recurring; one just does it faster and with less paperwork.
Real-world incident tooling shows this convergence in practice. Teams running incident response through chat-based tools alongside a formal ITSM platform typically split the work: engineers act and communicate in one layer, while structured records — categorization, timestamps, approvals — sync automatically into the system of record. Nobody re-types the same information twice, and the compliance trail still gets built. That pattern — fast action layer, automated sync to the governance layer — is quietly becoming the default architecture for mature incident response, and it works because it doesn’t ask either discipline to give up what it’s good at. Per incident.io’s own benchmarking, elite response teams resolve incidents in under an hour and get alerts to a human responder in under two minutes — numbers that only hold up when ITIL-style record-keeping happens automatically in the background instead of manually, mid-fire.
What Mature Organizations Do Differently
Organizations that get this right don’t pick a side. They treat ITIL 4 as the operating model for governance, risk, and cross-team consistency, and they treat agile/Lean practices as the execution mechanics inside individual value streams. Change enablement stays an ITIL practice, but standard changes get pre-approved so a sprint team can ship without waiting on a CAB. Incident management stays an ITIL practice, but the actual response happens in whatever tool the engineers already live in, with the record synced back automatically.
This is close to the reasoning behind Desqcon’s AEIOU approach to ITSM maturity — Automation, Edification, Integration, Operations, and User experience as five lenses you run every practice through, regardless of which methodology birthed it. Automation asks whether a practice like change enablement has pre-approved paths for low-risk, high-frequency work. Edification asks whether the people running problem management sprints actually understand why the ITIL practice exists, not just the mechanics of the ceremony. Integration asks whether your Kanban board and your CMDB are talking to each other or living in separate universes. Operations asks whether the process survives contact with a 2 a.m. outage. User experience asks whether any of this makes life easier for the person who just wants their access request approved. None of those five lenses cares whether the underlying practice came from an ITIL manual or a Scrum guide — vendor-neutral by design, because the framework you started with matters less than whether it’s actually delivering value today.
A Practical Blueprint for Blending Both
Start by mapping your value streams, not your org chart. Pick two or three end-to-end flows — “request to fulfillment,” “incident to resolution,” “idea to production” — and trace which ITIL practices and which agile mechanics already touch each one. You’ll usually find redundant approval steps that can be automated away and missing feedback loops that a sprint cadence would fix immediately.
Next, split governance from execution deliberately. Governance defines what needs approval, what needs a record, and what risk tolerance looks like. Execution decides how the work actually gets done inside that boundary — sprints, Kanban, pairing, whatever fits the team. ITIL 4 practices define the “what” well; they were never meant to dictate the “how.”
Finally, measure flow and value together, not process compliance alone. SLA percentages tell you if you hit a deadline. Cycle time, change failure rate, and time spent in continual improvement backlogs tell you if the work is actually getting better. Track both, and stop treating framework adherence as the goal instead of the mechanism.
Where to Go From Here
Neither ITIL 4 nor agile ITSM is the finish line — they’re both inputs into a maturity level your organization either has or doesn’t. If you’re not sure where the gaps actually sit between your governance model and your delivery speed, a structured ITSM maturity assessment is a low-drama way to find out before the next reorg or tooling migration forces the question. Desqcon runs these as a vendor-neutral read on where your practices stand today and what’s worth fixing first — no framework allegiance required.