Part five and the epilogue. After classical strategists, comedy-song philosophers, and sacred texts, the natural place to land: how ITIL compares with the modern frameworks in its industry.
After four essays comparing the ITIL guiding principles with classical and sacred texts, an obvious question has hung over the project: what about the modern frameworks? ITIL does not exist in isolation. It shares its industry with Lean, Agile, Scrum, DevOps, Kanban, and SAFe, all of which have carefully articulated principles developed by experienced practitioners, and most of which are taught alongside or in opposition to ITIL in conversations with the same client organizations.
This essay closes the series by asking that question. Where do these frameworks converge with ITIL? Where do they extend it? Where do they diverge? And what should an IT leader take away from those convergences and divergences when choosing or combining them?
A note on my standing for this entry. I have spent more than fifteen years working with Lean, Agile, and Scrum. I teach DevOps. I hold multiple SAFe certifications. I am an experienced ITIL 5 trainer. Unlike the prior essays, this one is written from within the frameworks rather than from outside. I have not asked an AI to find these parallels for me. I know them from practice.
The structure also differs from prior entries. The previous essays mapped a single source (or multiple sources) onto ITIL’s seven principles. This one walks through each framework on its own terms and in its own language, noting where its principles converge with ITIL’s, where they extend ITIL, and where they diverge. The frameworks examined are Lean, Agile and Scrum, DevOps, Kanban, and SAFe, in roughly historical order.
1. Lean
Womack and Jones identified five principles of lean thinking in their 1996 book of that title, distilled from decades of observing the Toyota Production System. The principles, in order, are: specify value (from the customer’s perspective), identify the value stream, make value flow, establish pull, and pursue perfection. Behind these principles lie other Toyota-era concepts: muda (waste), kaizen (continuous improvement), gemba (the actual place where the work is done), respect for people, and the discipline of mistake-proofing.
Convergence with ITIL
The convergence is dense. “Specify value from the customer’s perspective” is the same instruction as ITIL’s Focus on Value, expressed in identical terms. “Identify the value stream” is essentially the practice ITIL inherited, which became one of the four dimensions in ITIL 4. “Make value flow” maps to several ITIL principles at once: Progress Iteratively with Feedback, Optimize and Automate, and Keep It Simple and Practical. “Establish pull” is what ITIL calls demand-driven service consumption. “Pursue perfection” is continual improvement, which has its own ITIL practice.
Where Lean extends ITIL
Lean adds two things ITIL does not enshrine. First, gemba: the insistence that you cannot understand a process from a conference room and that the work must be observed where it actually happens. ITIL endorses observation but does not make it central. Second, muda: Lean’s vocabulary for waste is more developed than ITIL’s, with eight categories that an organization can systematically hunt down.
Where they diverge
Lean emerged from manufacturing, where the unit of value is a physical product and waste is visible and measurable. Service work is messier; the product is often co-created with the consumer in real time. Some Lean tools translate cleanly to service contexts, while others do not. ITIL’s framing of value as subjective and consumer-defined partly recognizes that the manufacturing analogy only goes so far.
2. Agile and Scrum
The Agile Manifesto, written by seventeen software developers in February 2001, articulates four values and twelve principles that have shaped most subsequent thinking about software development. The values are familiar: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The twelve principles elaborate on these values: customer satisfaction through early and continuous delivery; welcoming change; frequent delivery; business and developers working together; motivated individuals; face-to-face communication; working software as the measure of progress; sustainable pace; technical excellence; simplicity; self-organizing teams; regular reflection and adjustment.
Scrum, the most widely adopted Agile framework, adds structureits through three roles (Product Owner, Scrum Master, Developers), five events (the Sprint and the four ceremonies), three artifacts (Product Backlog, Sprint Backlog, Increment), and five values (commitment, focus, openness, respect, courage).
Convergence with ITIL
The convergence is strong. “Customer collaboration” and “early and continuous delivery” fall under Focus on Value. “Welcoming change” and “regular reflection” fall under Progress Iteratively with Feedback. “Self-organizing teams” and “individuals and interactions” fall under Collaborate and Promote Visibility. The Manifesto’s tenth principle (“simplicity, the art of maximizing the amount of work not done”) is, almost word for word, Keep It Simple and Practical.
Where Agile extends ITIL
Agile places a much stronger emphasis on team autonomy and the conditions for psychological safety. ITIL’s principles describe what good service management looks like; Agile is more insistent on how the team has to be set up for those principles to be realized. Motivated individuals, face-to-face conversation, sustainable pace, and self-organization are claims about the conditions of good work, not about the work itself.
Where they diverge
Agile and ITIL emerged from different communities for different reasons. Agile was a developer-led reaction against waterfall project management; ITIL was an IT operations response to chaotic service environments. Over a generation, the two have slowly recognized they are addressing the same problem from different angles. ITIL 4 explicitly incorporated Agile thinking; Scrum and SAFe have adopted the value-stream thinking that Lean and ITIL share. The convergence is now substantive, but the cultural memory of opposition still influences how teams adopt them.
3. DevOps
DevOps does not have a single canonical list of principles, but two formulations have become standard. The CALMS model (Culture, Automation, Lean, Measurement, Sharing) is the simpler one, often used in training. The Three Ways, articulated by Gene Kim in The Phoenix Project and developed in The DevOps Handbook, are the deeper formulation: the flow of work from development to operations to the customer, the feedback loop running in the opposite direction, and continuous learning and experimentation that improve both.
Convergence with ITIL
The convergence is the densest of any framework in this comparison. Culture maps to Collaborate and Promote Visibility. Automation maps to Optimize and Automate, almost identically. Lean is its own framework, already covered. Measurement and Sharing map to Progress Iteratively with Feedback. The Three Ways line up the same way: the first way (flow) is Focus on Value; the second way (feedback) is Progress Iteratively with Feedback; the third way (continuous learning) combines continual improvement with Optimize and Automate.
Where DevOps extends ITIL
DevOps operationalizes the cultural change ITIL describes more abstractly. ITIL says collaborate; DevOps says break down the wall between development and operations, conduct blameless postmortems, and adopt a you build it, you run it approach. ITIL says automate; DevOps insists on continuous integration, continuous delivery, and infrastructure as code. The principles are the same; DevOps is more prescriptive about what they look like in practice.
Where they diverge
There is no real divergence between DevOps and ITIL anymore, despite years of practitioners on both sides claiming otherwise. ITIL 4’s value streams, its swarming practice for incident management, and its explicit Agile alignment have dissolved most of the historical conflict. The remaining tension is cultural and organizational, not philosophical: DevOps comes from product engineering, ITIL from operations management, and teams in each tradition still suspect the other of not understanding what they do. The frameworks themselves no longer clash.
4. Kanban
David J. Anderson’s Kanban Method, formalized around 2010, takes the Toyota signaling tool of the same name and turns it into a method for evolving an organization’s work without restructuring. Four foundational principles: start with what you do now; agree to pursue evolutionary change; encourage leadership at all levels; and respect current roles, responsibilities, and titles. Six core practices: visualize the work, limit work in progress, manage flow, make policies explicit, implement feedback loops, and improve collaboratively while evolving experimentally.
Convergence with ITIL
The convergence is striking, sometimes verbatim (because ITIL has copied good ideas). “Start with what you do now” is Start Where You Are, using identical phrasing. “Pursue evolutionary change” is Progress Iteratively with Feedback. “Visualize the work” and “make policies explicit” are Collaborate and Promote Visibility. “Limit work in progress” and “manage flow” map to Keep It Simple and Practical and to Optimize and Automate. “Implement feedback loops” is again Progress Iteratively with Feedback. “Improve collaboratively, evolve experimentally” is the same.
Where Kanban extends ITIL
Kanban insists on visualizing the actual work, not just the process model of that work, a practical requirement ITIL does not enforce. The Kanban board (on the wall or in the tool) is a different artifact from a process diagram and tells you different things. Kanban also operationalizes what limiting work in progress means in practice, which ITIL’s call for simplicity does not fully cash out.
Where they diverge
Kanban does not diverge from ITIL. It is best understood as a complementary method that applies ITIL’s principles and gives them a specific operational form for teams that are not ready to restructure into Scrum or SAFe. Its respect for current roles and titles is itself a Start Where You Are principle, and its evolutionary character mirrors ITIL’s continual improvement model.
5. SAFe
The Scaled Agile Framework, in its current version, articulates ten Lean-Agile Principles: take an economic view; apply systems thinking; assume variability and preserve options; build incrementally with fast, integrated learning cycles; base milestones on objective evaluations of working systems; make value flow without interruption; apply cadence and synchronize with cross-domain planning; unlock the intrinsic motivation of knowledge workers; decentralize decision-making; and organize around value.
Convergence with ITIL
The convergence is substantial. “Take an economic view” and “organize around value” are part of Focus on Value. “Apply systems thinking” is Think and Work Holistically, using nearly identical language. “Build incrementally with fast, integrated learning cycles” is Progress Iteratively with Feedback. “Make value flow without interruptions” is Optimize and Automate, combined with Keep It Simple and Practical. “Decentralize decision-making” is implicit in ITIL’s Collaborate and Promote Visibility but is more directly stated in SAFe.
Where SAFe extends ITIL
SAFe goes further than ITIL in three ways. First, “assume variability and preserve options” is a stronger statement about uncertainty than ITIL makes; SAFe insists that committing to a single design too early is a failure mode and treats optionality as a value worth preserving. Second, “apply cadence, synchronize with cross-domain planning” gives a specific operational shape (the Program Increment and the PI Planning event) to coordination that ITIL describes more abstractly. Third, “unlock the intrinsic motivation of knowledge workers” is a claim about what makes work productive that ITIL gestures at but does not name directly.
Where they diverge
SAFe is, in practice, much more prescriptive than ITIL. Where ITIL says “collaborate,” SAFe says, “hold a PI Planning event with all teams in the same room every eight to twelve weeks.” Where ITIL says “iterate,” SAFe says, “two-week iterations within ten-week Program Increments with quarterly inspect-and-adapt sessions.” This level of prescription can be a strength (it removes ambiguity about what the principle requires in practice) and a weakness (it can lock organizations into ceremonies that do not fit their actual situation). ITIL’s intentionally lighter touch leaves more room for organizations to find their own expression of the principles, which is the point of having principles rather than rules in the first place.
Five Frameworks, Same Seven Principles
Five frameworks, all comparing favorably with ITIL’s seven guiding principles and extending ITIL in specific places, almost none truly diverging from it. The pattern that emerged in the earlier articles in this series, where Machiavelli, Sun Tzu, fourteen philosophers, and fourteen sacred texts converged on the same core ideas, repeats here in an unsurprising form. Modern management frameworks designed for the same domain and developed by practitioners working on the same problems converge even more tightly than the cross-millennial comparisons did. They had to.
What emerges from this comparison is not a winner. ITIL is not better than DevOps. SAFe is not better than Kanban. Lean is not the foundation of the others, even if its vocabulary appears in most of them. Instead, what emerges is recognition that the frameworks address different parts of the same problem, with different emphases. An organization that picks one and dismisses the others makes the same mistake as the practitioner who reads only Machiavelli or only Sun Tzu. The frameworks are complements more than substitutes.
A practical note for IT leaders. If you have been told that ITIL and DevOps are incompatible, that ITIL is heavyweight and Scrum is lightweight, or that SAFe is bureaucratic and Kanban is freeform, you have been told something that was true a decade ago but is no longer. The frameworks have learned from each other. The communities have matured. The remaining conflicts are organizational and cultural, not philosophical. Choose the framework or combination whose vocabulary your organization can adopt, and recognize that whichever you choose, you will be working with the same underlying principles. The names differ. The substance does not.
Across this series, the recurring finding has been the same seven principles. Machiavelli on governance. Sun Tzu on competition. The philosophers on what value is, what evidence is, and what wholes are. The sacred texts on covenant, community, and practice. Now the modern frameworks on flow, feedback, and collaboration. The same seven principles keep appearing, articulated differently each time by people who had no idea they were articulating the same thing as the others.
The tools change. The principles endure. By the close of this series, the principles look less like ITIL’s contribution to IT and more like IT’s belated discovery of what humans organizing themselves to manage shared, complex activity have always understood.
About the Author
Dane is an accredited ITIL 5 trainer and consultant based in Sweden. He has delivered more than 400 ITIL courses to more than 4,600 students across all certification levels. He also teaches DevOps, holds multiple SAFe certifications, and has worked with Lean, Agile, Scrum, and Kanban for more than fifteen years. This is the fifth and final entry in a series comparing classical, sacred, and modern frameworks to the ITIL guiding principles.
This article was first published on Substack on May 12, 2026.