Time for CIOs to deploy agile methods

Agile working holds great potential for chief information officers who, once converted, are unlikely to turn back


The Agile Manifesto was written way back in 2001, but some companies are only just making the transition. The philosophy is that it’s better to iterate fast, and to collaborate with customers to tweak and improve, rather than stick to a plan. Agile is about responding to events and feedback, tacking and jibing fluidly.

Insurance company Aviva is one of the latest to make the shift. Chief information officer (CIO) Monique Shivanandan recalls: “When I joined Aviva in 2014, agile was seen as ‘an IT thing’ and was only being used in small pockets. With great support from our CEO, we aggressively rolled out agile across Aviva’s UK businesses.”

The impact was immediate. Ms Shivanandan says: “Success is infectious, so very quickly we had agile teams sprouting up across the business. At the end of 2015, over 85 per cent of our change portfolio was delivered leveraging agile.”

As agile has moved to mass adoption, CIOs have learnt more about the best ways to deploy it

Product output has been radically improved. “Agile started small in Aviva, but once people could see it was working it started to snowball. Now circa 65 per cent of all change globally is delivered using agile. We have gone from three or four IT releases a year to large monthly releases and frequent daily releases of product enhancements,” she adds.

Deploying agile methods

As agile has moved to mass adoption, CIOs have learnt more about the best ways to deploy it. For example, bottlenecks need dealing with.

Gunnar Menzel, chief architect officer at Capgemini Infrastructure Services, says: “Unfortunately, few companies have realised agile’s full potential because the delivery of end-to-end flow and speed is constrained, especially by downstream activities such as integration testing and release management.”

The solution? DevOps has arisen, in which all departments collaborate to keep agile moving. The software team is no longer in isolation. Like the agile thinking it supports, this must become a way of life if companies are to get the most out of it.

Mr Menzel says: “Each individual area within the organisation can either contribute to DevOps success or act as inhibitors. For instance, IT leadership can prove detrimental if it lacks a clear vision, assumes that DevOps is something the organisation can buy or fails to provide adequate room for change.”

Learning what works

As more CIOs use agile, there is also a greater consensus on what doesn’t work. For example, Future Processing is an outsourcing company which uses the scrum version of agile for most of its software projects.

Yet chief executive Jaroslaw Czaja has learnt a few lessons, which other C-suite executives need to heed. First lesson: pick the agile method to fit the job. Mr Czaja says: “Agile is a collection of different methods; for example, there is scrum, kanban, scrumban, extreme programming and so on. You need to pick the right agile method if you are going to succeed.”

Second lesson: know where agile won’t help. Mr Czaja adds: “Short projects may be unsuited to agile, if the wrong method is chosen; for example, scrum because there’s not enough time to see the benefits.”

Highly regulated industries and products with tight pre-defined specifications may also be resistant to agile. Paco Hope, principal security evangelist at Cigital, which works with CIOs on agile software development, says companies need to identify the point at which agile is no longer suitable and old-fashioned “waterfall” planning must be used.

“At every organisation there is an agile-waterfall boundary,” says Mr Hope. “For slow-moving, highly regulated industries, agile methodologies are like salt – a bit can make things taste better, but too much will spoil it. For industries that are faster and have less regulatory burden, agile methods are meat and drink. They tend to grant a competitive advantage over non-agile businesses.”