By Josh Roberts | June 30, 2014 | 0 Comment
This is the third organization in which I have been part of an ITIL implementation. This is also the third instance where an Agile/Lean transformation was occurring at the same time. As is often the case, people naturally question how ITIL and Agile practices differ. More specifically, can both sets of practices work together in a harmonious way? The answer is definitely, YES!
First, note my choice of words; ITIL “implementation” versus Agile/Lean “transformation”. As with many process implementations, ITIL is usually implemented in conjunction with a new tool and process library. An Agile/Lean transformation will introduce new practices, but places an emphasis on transforming the people/culture over implementing process and tools. As such, we must also examine the alignment of ITIL and Agile/Lean cultures.
According to Wikipedia, “The Information Technology Infrastructure Library (ITIL) is a set of practices for IT service management (ITSM) that focuses on aligning IT services with the needs of business”. A focus on the needs of the business sounds very Agile, but the key difference is the concept of “Service Management”. Agile practices focus on delivering value to the customer in the form of building, or configuring software, while ITIL is focused on managing a Service for the customer. So, how does ITIL define a Service?
ITIL defines a Service as, “A means of delivering value to Customers by facilitating Outcomes Customers want to achieve without the ownership of specific Costs and Risks.” With that definition, I can understand why people question the difference between ITIL and Agile practices. It is easy to confuse a Service life-cycle with a Systems Development Life-Cycle (SDLC) such as Waterfall, Spiral, Agile, RAD, etc. It is important to note that nowhere in the ITIL practices is an SDLC prescribed.
As we seek to better understand what defines a Service, let’s focus on the Service Catalogue. I found some great examples, at this link.
The State of North Carolina’s service catalog defines services such as cellular phones, hosting, audio conferencing, etc. For each of these services, the service catalogue provides a description that includes cost, availability, SLAs, and how to order the service. You will also see “Application Development and Support” listed as a service. Not for a specific application, but for the services offered by the Software Development department as a whole. Remember, ITIL prescribes a set of practices for managing the Service life-cycle (i.e. Service Strategy, Design, Transition, and Operation), but does not offer practices for building a laptop, installing a phone, or developing/configuring software.
Here’s a good analogy that I have been using lately. If you are in the process of relocating, one service you are seeking is “shelter”. Before you jump into a home search, you will naturally define your requirements for shelter. You don’t start with functional requirements (e.g. floor plan, carpet color, hardware, etc), rather you think about the requirements of the shelter itself (e.g. capacity, availability, security, etc). For example, if you require your shelter to have capacity for 2 people, be available for 1 mo, and have moderate security, a hotel room may be sufficient. If it’s 6 people, for 5 years, with high security, you might need a home in the suburbs.
Why does ITIL not prescribe an SDLC? Because you might choose to buy your service versus build it. In our example, if you do decide to build a home, you will use a development life-cycle to handle your functional requirements. If you buy/rent a home, you will use a service life-cycle to transition into the home and operate your new shelter.
Can application software be defined as a service? Yes, but it may be done as a collection of system(s) that deliver value to a customer. For example, Customer Billing could be defined as a service. As a system, it is made up of multiple software applications that collect the transactions, rate them, perform billing, and produce a statement. Alone, these applications do not deliver value. However, together they do provide value to the business, along with a cost, SLAs, and assets under configuration. Using the Scaled Agile Framework (SAFe) for enterprise software delivery, this is what an ITIL integration might look like at a VERY high level.
So with the practices in alignment, what about the ITIL and Agile cultures? While ITIL once focused on “minimizing” change to the production environment (contradicting frequent value delivery), it is now very much focused on “managing and communicating” change in a collaborative and visible way (e.g. CAB, RFCs, Change Calendars, etc). And, for example, the goal of the Change Advisory Board (CAB) is to bring the IT and business organizations together to collaboratively understand the impact of change to the production environment. There’s no reason you couldn’t run your CAB using Agile techniques (maybe a Kanban board?). There is even a hint of DevOps here.
Other similarities between ITIL and Agile practices include coordinated release plans and continuous improvement mechanisms. Like Agile practices, ITIL seeks Continual Service Improvement (CSI) by using Deming’s Plan-Do-Check-Act cycle.
The key to a harmonious relationship between ITIL and Agile practices is that we continue to place a greater value on collaborative, cross-functional teams over ITIL’s focus on managing organizational hand-offs (i.e. silos).
“Individuals and interactions over process and tools” – Agile Manifesto
There are good practices in both ITIL and Agile. By applying Agile/Lean thinking, we can keep a focus on the human system and optimize the organizational processes as a whole.