Skip to main content

Part of ITIL 4’s value proposition is that it embraces newer ways of working, such as Agile, Lean and DevOps.

I was recently asked whether there was a compelling argument for individuals to go to ITIL for information about these approaches, vs. going to ‘the source’. Here’s my answer and I’d love to hear yours.

3) What source? Yes. There is a massive amount of information available about these topics. There are many ‘definitive’ sources of knowledge. For lifelong learners such as myself, these sources are a joy. They can also be overwhelming and at times a challenge to apply. A search for information about Lean, for example, may take you down a manufacturing route which then requires translation. Looking to learn more about Agile? Which method? Scrum, SAFe, extreme programming … you get the point.

2) The source is evolving. As an example, DevOps practitioners often pride themselves in the fact that there is no definitive body of knowledge; rather, there is an evolving collective body of knowledge. The same can be said for topics such as Site Reliability Engineering and DevSecOps. Here’s what is cool about many of these emerging and evolving practices. The evolution is often enhanced by applying principles originally introduced in, wait for it…Lean and Agile. Just as we see Lean principles being applied to modern software development practices such as continuous delivery, and we see Kanban (a Lean technique) being used to prioritize and manage work (including things like incidents and problems).

1) It’s about integration! For organizations that have invested in ITIL, what the framework now does is describe what an integrated approach looks like and how organizations can incorporate these frameworks and methods to meet their current circumstances and needs. ITIL is not trying to be ‘the source’ relative to these topics. It’s trying to acknowledge and embrace the roots of modern-day work. For organizations leveraging these approaches (and who may have turned away from ITIL in the past as being out of date), they can now see themselves in the framework and perhaps be open to exploring ways that ITIL actually can help; particularly in the context of IT service management (ITSM) where it is widely recognized as ‘the source’.

Is ITIL behind the curve in terms of the latest emerging practices being used by elite performing organizations? Yes. It is a best practice framework and best practices, by their nature, lag behind. The organizations out on the leading edge are paving new roads and will report back along the way.

For many organizations, however, they are just finding concepts such as Lean and Agile and DevOps and so I’m hearing regularly that it is validating to see these concepts being brought into ITIL 4 and integrated with ITSM best practices.

Here’s what we don’t want. Framework silos. For years, we’ve heard about silos. Dev vs. Ops. Lean vs. Agile. ITIL vs. DevOps. It’s time to embrace the fact that there is no ‘vs.’ in these conversations. In the highest performing organizations, you’ll often find that the answer is D. All of the above. And not necessarily in a ‘pure’ form. These organizations recognize that rules are a good start, but it’s ok to bend or break them when needed. Or as is emphasized in ITIL, adopt and adapt. The highest performing organizations take inspiration from any and all sources and figure out what works for them at that time. As continuous improvement is a hallmark of these organizations, it is also not long before these elite performers are looking for inspiration for their next round of improvement. Often by going back to ‘the source’, whichever source that might be. At times going back to the basics. Other times diving off the leading edge. It depends.

Therein lies the value of bringing concepts such as Lean and Agile and DevOps into ITIL. For individuals and organizations unfamiliar with these concepts, it provides a ‘whetting of the appetite’ so to speak that can then lead to further exploration, experimentation, and learning. For individuals familiar with these concepts or experiencing them in their organizations, it provides validation that an integrated approach is, in fact, best practice.

So, here is what I hope; that individuals attending ITIL education, whether an introductory or advanced class, get exposed to a new (even if only to them) concept and then are inspired to go beyond the books to learn more. Go to ‘the source(s)’. Learn about the thought leaders behind those sources. Whether early thought leaders such as Deming, Juran, and Ishikawa, or contemporary thought leaders such as Orzen, Sutherland, Kim, Humble, the ITIL authors and individual contributors and others too numerous to list. In times of constant change such as these, the key is to just keep learning!

Originally published on linkedin.com, written by Donna Knapp, Curriculum Development Manager at ITSM Academy

To learn more, please visit http://www.itsmacademy.com/resourcecenter

Comments

Popular posts from this blog

What is the difference between Process Owner, Process Manager and Process Practitioner?

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you.

Roles and Responsibilities:
Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance.Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the policies (r…

How Does ITIL Help in the Management of the SDLC?

I was recently asked how ITIL helps in the management of the SDLC (Software Development Lifecycle).  Simply put... SDLC is a Lifecycle approach to produce the software or the "product".  ITIL is a Lifecycle approach that focuses on the "service".
I’ll start by reviewing both SDLC and ITIL Lifecycles and then summarize:
SDLC  -  The intent of an SDLC process is to help produce a product that is cost-efficient, effective and of high quality. Once an application is created, the SDLC maps the proper deployment of the software into the live environment. The SDLC methodology usually contains the following stages: Analysis (requirements and design), construction, testing, release and maintenance.  The focus here is on the Software.  Most organizations will use an Agile or Waterfall approach to implement the software through the Software Development Lifecycle.
ITIL  -  is a best practice for IT service management (ITSM) that focuses on aligning IT services with the needs …

Incidents when a Defect is Involved

Question: We currently track defects in a separate system than our ticket management system. With that said, my question is does anyone have suggestions and/or best practices on how to handle incidents when a defect is involved? Should the incident be closed since the defect is being worked on in another defect tracking system if it is noted in the incident ticket? I am considering creating an incident statuses of 'closed-unresolved' so the incident can still be reported on in our ticket management system but know it is being worked on/tracked in the defect system. With defects, it is possible that we may never work on them because they are very low priority and the impact is low to the user. However, in some cases a defect is being worked on. Should we create a problem ticket instead?
Thanks, René W.

Answer: René. In ITIL, the activity you are describing is handled by the Problem Management process. ITIL does not use the term “defect” but it does use the term “known error” to…