While we strive to deliver at pace there can be an over-confidence and a positioning of past policies and frameworks as being too rigid, of failing to allow the freedom with people to get on with their work.
Some see ITIL as a restriction on innovation and a provision of quality, assurance and security by checkbox only, rather than being reflected in reality. Others look at agile methodologies as taking a lax disregarding attitude to quality and service responsibilities. Some of these criticisms are perhaps accurate when we look at some of the ways they have been applied, both properly and improperly. There are no intrinsic failings here though, the reality of poor application is the lead in to poor outcomes. In many ways the targets are the same and merely act as facets of the same underlying goals.
ITIL is agile
As with all methods of working, time and technologies change and we adapt ourselves and them to meet the new challenges. ITIL however is seen as inflexible at times as it is indeed a formal specification of processes and tools. But by stepping back from the exact procedures laid out we can see that at a higher level there is no real sense in which agile has a natural conflict with the ITIL framework.
Through user research and prototyping it targets the customer needs in a direct manner. Through embracing constant stakeholder engagement and demoing it strengthens the relationship between the business and the outcomes. Avoiding the pitfall of large timescales between static requirements gathering and delivery that all but guarantees non-optimal delivery for the business.
The natural focus on iteration and user-engagement also means that the service evolves during its lifecycle, responding to changes in the external landscape and user needs. All these are core to the principles ITIL seeks to embody. The implementation may seem somewhat alien to those who have worked in more traditional atmosphere, but in many ways the principles are universal to both.
Agile is not lazy
Agile approaches do not preclude quality checks it actually requires them to be built into the fabric of the way you deliver. Automated, silently and transparently providing the same guarantees more formal techniques such as change management is designed to give us.
While many of the ways we traditionally provide support and the procedures around that support still apply, the scope and functionality provided to us by modern systems also allows us to design proactive methodologies. We no longer expect to react to problems and user complaints, we see this now as a failure in our monitoring and testing. Instead the system alerts us when anything untoward is happening. Through metrics and benchmarking we are notified to abnormalities that will affect users. And by smoke testing real user stories, or even running virtual users on our services 24/7, we seek to ensure that it is never an actual user that spots an issue or suffers degraded service, but instead an automated alert or virtual user that calls us to tell us when something needs improved.
Stepping back
There is no sense in saying that ITIL and agile are the same. They come from fundamentally different management viewpoints. In some ways agile is there to challenge some of the tenets of the more formal processes and to break down the inflexibility that we can see in the over-strict use of formal methodologies. This does not mean that the two are completely estranged though. There is much that an ITIL practitioner would recognise and be reassured by when seeing agile being practiced well in the workplace. Similarly, there is much for the agile practitioner to relate to in the more formal sphere. The way things are carried through in reality is the key differentiator between in management styles. Good agile is a lot closer to good ITIL than it is to the bad version of itself.
