ITIL 4 marries SAFe, but can it last?

Isn’t that a good question?

At least I get a lot of questions about the synergies between ITIL and SAFe, and therefore, I have decided to put my thoughts here with the hope they provide some clarity for the ones of you out there, being in a similar situation.

The Common Misconception

More often than not, people do not see how ITIL, SAFe or any other management frameworks / methodologies / schools of thought can work together. They are focused deeply on one or the other, constantly arguing about which one is better. One of the default argument is “Agile is better than Waterfall”, nevertheless, this argument is different, as these are closely related disciplines.

Our topic here goes into another direction. I want to dive into the question of how frameworks of different disciplines can complement or negate each other. Therefore the more appropriate question (and I also get that a lot) is “We are doing SAFe, why would we need ITIL?” (or vice versa).

Indeed, right? Why would I need both if I am already doing one of them? The short answer is “Because they can nicely complement each other”, and for the long answer, please scroll further 🙂

Example Situation

Imagine a mid-size company with 500-1000 employees. Too big to act as a start-up, too small to have all the resources for all the advanced frameworks (e.g. a full SAFe configuration or governance with COBIT). A lot of potential, the possibility to act fast on the ever-changing market of customer requirements, and the need for some level of control for a structured Service Management.

A very fertile ground for the seeds of success but also for the ones of confusion.

Probably, there have been some advances on the front of service operation/support by utilizing the appropriate practices from ITIL. Probably, there is an Incident Management practice in place, along with Service Request Management, Change Enablement and perhaps Problem Management. There usually is a more or less advanced Service Desk, perhaps utilizing a Knowledge Base.

And now, someone drops the bomb (maybe in the IT management team or even the C-Level suite) “Let’s start using SAFe” BOOOOM.

Common Conflicts

SAFe and ITIL seemingly don’t fit together very well, or at least that can be the first impression if we fail to see the big picture and recognize its beauty. Therefore I would like to quote one of the ITIL 4 Guiding Principles (spoiler alert) “Think and work holistically”.

Let’s take one step back and let’s understand what SAFe and ITIL are and what they are not:

• ITIL is a collection of good practices in the wider area of Service Management
• SAFe is a framework, which helps companies to scale agile product development across the organization
• ITIL is not descriptive, meaning it does not tell us how to do something, it only tells us what should be done to be successful
• SAFe is very prescriptive and very thorough in telling us what needs to be done and how (it even comes with a dedicated implementation roadmap)
• Both can be applied as stand-alones but it is better to look for synergies to increase the overall value they have towards the organization

Requests for Changes vs. User Stories

Probably one of the most common conflict between any Agile methodology and ITIL. “How do we handle Changes when we are aiming for agility?” That could be the 1 million dollar question on Who Wants to Be a Millionaire?

The answer is quite simple though. User Stories, Features, Enablers and Epics can be seen as RFCs. Simple as that.

ITIL states that an RFC is:

A description of a proposed change used to initiate change enablement.

The Change Enablement is:

The practice of ensuring that risks are properly assessed, authorizing changes to proceed and managing a change schedule in order to maximize the number of successful service and product changes.

And for those who utilized ITIL v3 or earlier versions, I would like to mention the CAB (Change Advisory Board), which is now the called the Change Authority:

A person or group responsible for authorizing a change.

I don’t know about you, but for me this sounds familiar when I think about SAFe.

RFC = User Stories, Features, Enablers and Epics –> These are descriptions of the requirements

CAB = Product Owner / Product Management –> Deciding what gets implemented and responsible for the acceptance once the task is done

Handling Support

Another hot topic. Why? Because SAFe does not really give us thorough guidance on how support should be organized. Well, generally it says that you should have DevOps (or even better DevSecOps) teams, which are organized into Value Streams and which include all needed capabilities (e.g. Development, Testing AND Support) required by that Value Stream. This would mean that any of the team members would also be responsible for the support of their Value Stream. They could handle their Incidents as backlog items, which would be included in their Team Backlog, and they would utilizes methods like swarming to handle those Incidents.

However, in real life, organizations are not always utilizing Value Streams and team structures are still based on functional silos.

Therefore, it is of utmost importance to have a stable Incident Management in place, which includes everybody, across all teams, who is needed to guarantee support. Please note that ITIL 4 does not talk about support levels anymore. There is no 1st, 2nd and 3rd level support. There is a Service Desk and there are specialist teams. And those specialist teams could even be the SAFe Agile Teams.

The Service Desk

Oooooo, a good one, right? “How should that be set up”, you ask…”Do we even need a Service Desk”, you ask…”But they only have operational work”, you say….and right you are.

SAFe does not include the role of a Service Desk, but most organizations traditionally have one (and that is absolutely fine). You do not need to break up the Service Desk and distribute all its people to the individual agile teams working in the Value Stream. Since the Service Desk has close to 100% operational work, they don’t need to be fully integrated into the SAFe framework. But be aware! This does not mean that they should be excluded. First of all, it is not a nice feeling to always be the outsider. And second of all, it might actually happen that the Service Desk is involved in projects where it makes sense to include them.

On the other hand, it does not make much sense to include the complete Service Desk in all SAFe events (Planning, Review, Retro, Inspect and Adapt, PI Planning and whatnot…). Instead, you could just appoint a representative. The benefit would be to keep the Service Desk updated on what new services, tools and features will be implemented in the next PI (Program Increment), so they are not surprised when a user is calling them with an issue in the latest feature of the new business app XYZ.

The Terminology

That is a very persistent issue. I spent a lot of meetings/calls with discussing the meaning of different words, which were completely clear to me (thanks to my ITIL background) but were complete nonsense for people with a different history.

One of the topics always popping up is “RFC” vs. “Story” or “Defect” vs. “Bug” vs. “Incident”.

The best thing here would be to educate the people, have a look at the official glossaries (e.g. the ITIL 4 Glossary and the SAFe Glossary) and if needed, create an own glossary with all agreed terms and abbreviations.

Service Level Agreements

A common misconception here is that SLAs are only needed for support or for the Service Desk, but that is not the case.

Service Level Agreements are:

Documented agreements between a service provider and a customer that identify both services required and the expected levels of services.

This means that they should cover all aspects of Service Delivery, including development and support. Nevertheless, it is already a good starting point to have basic answer and resolution times for Incidents included. The catch here is to decide how to handle operational tasks (e.g. Incidents or Service Requests) versus plannable tasks (e.g. Stories or Epics) in an agile environment. More about that can be found in the “Common Pitfalls” section under “Handling Support Tasks”

Common Pitfalls

Not seeing the overall picture

We should cast off our blinkers, allowing us to see the bigger system we are a part of. The relationship of ITIL, SAFe and other frameworks is not “OR” but “AND”.

There are many possibilities to link these frameworks with each other, but that can only work if we keep an open mindset and try to think outside of our main domain, while keeping in mind that we are all supposed to deliver value to our stakeholders. That said, we should educate our stakeholders and colleagues about the affected frameworks and we should document the values that will act as our guiding light.

Both SAFe and ITIL have their own set of values, though most of them are overlapping. We should agree on the ones that are most important to us and communicate those organization wide.

Here are some additional thoughts by Scaled Agile on Systems Thinking.

Handling Support Tasks

Basically, there are two options:

1. One backlog for plannable (Stories) and unplannable (Incidents) work
   • Requires a higher level of agile maturity
   • The Product Owner owns the backlog and with it the operational tasks, like incidents
   • The PO needs very clear guidelines (in the SLAs), which help him / her to prioritize operational tasks (e.g. to put an Incident into the current iteration or leave it for the next one)
   • Each team should have a quite precise estimation for each iteration on the ratio of plannable and unplannable work
2. Separate backlogs for plannable and unplannable work
   • Usually done in companies thinking more traditionally, where agility has not lit the fires of enthusiasm yet
   • Can lead to confusion for agile teams, as they need to work in two ticketing tools (one for DEV and one for OPS work)
   • Preferred by the operational teams, as they have always been working in usual ITSM tools

I have seen both in action and there is no real right or wrong. Nevertheless, I would recommend to go for one backlog for everything even if it requires more discipline, as it is simpler to work with one in the end.

“Culture eats strategy for breakfast”

This quote by Peter Drucker really hits the nail on the head. A transformation into an agile way of working can really divide the company into two major camps, the “Agile Evangelists” and the “Why should we change, it has always been working like this” people.

The main challenge is to put ourselves in the shoes of both. Try to understand their pain points and try to respond to those. Just because something was done in the past, doesn’t mean it is bad. To quote another ITIL 4 Guiding Principle, we should “Start where we are”, understand what is good and what needs to be changed, and then apply an iterative approach to reach our goals.

Nevertheless, we can strategize all we want, we can have all the cool ideas, there will always be people who will try to stand in the way of evolution. So how do we overcome this challenge?

Simply by being persistent about our new ways of working. At some point these new ways will become the new culture of the company, though it might take quite some time. Cultural change is estimated to happen 12-18 month after the introduction of the new ways.

Conclusion

To reflect on the title of this writing…Yes, the marriage of ITIL and SAFe can and will last, at least if we are able to see and understand the big picture of modern IT Service Management including an Agile Product Development.

• Modern frameworks can nicely complement each other when applied right
• Typical pain-points are found around the operational work (e.g. Incidents, Problem, Service Requests, etc…)
• We should always keep an open mindset and try to anticipate the best parts of both worlds

We would also appreciate if you would let us know what you think about this article or what other topics you would like to read about.

Leave us a comment below, contact us or find us on LinkedIn.