Recently I have had several discussions about using ITIL and agile together for developing and delivering global application services and the strengths of each.
For one application, application X, the client runs locally at user sites in different countries. Although most sites experienced a dramatic performance improvement, one European site i has poor performance. Is this due to the new release of the application or the site infrastructure running badly? Exploring the integration of agile and ITIL helps to identify gaps and what could be improved.
Within ITIL the characteristics of a service are measured as:
• Fit for Purpose (Utility)
• Fit for Use (Warranty)
Agile development methods enable delivery of the Utility. This means that a user can use an application to perform a business activity at the “right” speed e.g. processing a set of invoices in a set time. The Warranty enables service providers to guarantee that the application service will run continuously to deliver the Utility. This means the service will have sufficient capacity, be available, and secure.
Some people struggle with the term Warranty. The idea behind using Warranty is to encourage service providers to deliver the Warranty for the lifetime of the service, not just for a period after deployment to live production. In ITIL V3 this period, post go live, is called Early Life Support. This is a sign of industry maturity where service providers have a service management capability that means they can guarantee the Utility and Warranty.
For the global application above, users like the agile approach as they get what they want and improved performance – this was one of the objectives. However, there were a few cultural issues with some of the developers. The agile development team found they had to spend too much time in trying to communicate the requirements with a remote development team in Asia. The cultural differences were too great. This remote development has since moved to Italy and things are working well. The focus is back to delivering functionality and performance improvement. This took me back to some of the discussions around organizational and cultural change that we had when writing the ITIL Service Transition book.
For application X, the Utility depends on the performance of the central and local infrastructure services. If the application is slow, users blame the first thing that comes to mind – the application itself. This happened at the one site in Europe. The agile development team had identified the requirements for the infrastructure services but there was only a service level agreement with the central infrastructure team. There was no agreement with the local user site. The performance of the local network and infrastructure services on the user site degraded over time. This was probably the cause of poor application performance – it is still under investigation.
Applying the ITIL service modelling and practices through the service lifecycle will help the agile development teams to set and manage expectations earlier. Defining and managing the service requirements, service levels and dependencies with the local country site would have helped.
Organisations that really learn to do adopt agile methodologies and ITIL will be in a fantastic position to implement changes better, faster and cheaper. They will also be competitive during the rush to the new world and Web Services 2.O.
What do you think?
Any feedback and comments are always welcome!