ITIL v3 is a Framework for Change Management. The basic principal (at least my short version) is to make sure that any changes to a Production System Do No Wrong. ITIL has Processes to manage most aspects of an application environment.
Agile is a Framework to allow the quick creation of Applications or any type of work that gives almost immediate benefits to a company in short intervals called "Sprints".
Consider the following scenario;
Your company is ready to create a new enhancement to Product A and everyone is excited about its' release.
You follow all the standard conventions regarding Agile Development of release planning, having the team agree on the work they can get done for the next release, developer peer review, user testing, and all enhancements work as expected.
Everything goes as planned and now the release day has come!
Inevitably, there will be changes to the Database Structure. There may be new fields, new tables or even changes to the relationship of tables to each other. There may be a new web service to be installed.
The development team properly follows their script to make the changes necessary and everything seems to go fine. Another great release!
But is it true?
In this example, you accidentally caused an application in a remote city to not function as it is rarely used and no one thought about it. You do not find out for another 3 Sprints.
This is where ITIL change management comes into play.
ITIL keeps track of different aspects of the system and their relationships. The information about systems or applications are stored in a Configuration Management Database. Each component is called a CI.
The Configuration Management Database stores information about each component or CI and it's relationship to other components.
When you have implemented ITIL in its' entirety you would know that for instance the X Table is depended upon by Application X. Application Y may be running in a different city and only communicate once in a while; and therefore should not be forgotten.
What went wrong? That's easy; A lack of change control and this is where ITIL comes into play. No matter how we try, people cannot remember everything about all aspects of a large system. Factor in employee turnover and the results can be disastrous.
A properly documented Configuration Management Database would have at a minimum had someone ask "Hey, has someone thought about Application Y running out in that other city?".
This is where ITIL and Agile can complement each other.
During the Agile release cycle or Sprint, the ITIL management team should be given due consideration to ensure or plan for integration issues with other parts of the system. If you have the company process in place, this would likely have been done before it came to development.
Using ITIL before development starts can save the company huge expense by ensuring a project won't negatively affect other systems, well in advance. It provides a better overall general design before starting.
This in no way implies using a waterfall development approach!
It simply is about adding a few specs before starting stating something like "If the X table will be changed, don't forget about Application Y".
Another example might be "Application Y is multi-lingual. Make sure the new application supports more than one language".
This fits well with an Agile Project Directive without requiring complete specifications to be completed before development starts.
Thinking this way may seem to cause more overhead. However, compared to the cost and embarrassment of having to do a panic change and possible outages, the costs are minimal.
In reality, the software design and development phase of a system is a smaller part of the overall growth plans and service plans of a company.
Ideally, Agile development would properly address as part of an ITIL process. For many smaller companies though, this is not likely a reality.
Being a strong supported of Agile and ITIL myself, I can also see how the ITIL process (or parts of it) could benefit an Agile Team that is not currently in an ITIL environment.
During an early Sprint where some planning takes place, or at a later Sprint when things are almost ready for production would be great places to introduce some of ITIL's framework.
The bottom line is sharing of information.
Certainly, if you have made a big change, you will want your ITIL team to follow their processes of Service Transition. Why re-invent the wheel?
Consider the impact to customer churn rate and the stress to the support department when deciding if ITIL would be useful to your company.
Agile and ITIL can work together nicely if due consideration is given to both.
Nothing in life is perfect and every company has it's reasons why some things will work, and some won't.
Take what you can from each and truly benefit your company by putting out good code (Agile) and not destroying any production processes as you do it (ITIL).
I know there will be purists in both camps who read this and want to comment about how their way is the only way. Please read my blog disclaimer.
I believe that most companies can benefit from at least a small selection of both methodologies.
Using some of each methodology is better than using nothing at all. As a minimum, employees will have a common language to communicate and know how to get things done safely and efficiently.
Why not use what you can and get benefit from it for your company.