Does the Concept of Agile Recovery Make Sense?

‘Agile’ is still a buzzword. That’s quite a feat in today’s high-speed business and technological environments, where concepts date so rapidly. The original ‘Manifesto for Agile Software Development’ appeared in 2001, some 14 years ago. Since then, the word and the concept it labels have been applied to different business areas, including marketing and supply chain operations. Recently, it has also cropped up in the phrase ‘agile recovery’. But is this taking the ‘agile concept’ too far?

The big benefits of the agile approach in software development were the result of short development-test cycles that made teams focus on what customers really wanted. They concentrated functionality on what was useful and a priority, and avoided the problems of integration and testing in longer development efforts. That didn’t mean that every software development project had to be agile. The traditional waterfall approach was still valid in some cases. Likewise, ‘agile’ brought benefits to other areas and sectors of business, but not all. Construction (building) was a case in point, where waterfall methods were still a more realistic approach.

So what of ‘agile recovery’? Does an agile approach to IT with an agile IT team and an agile data centre automatically carry across to ‘agile recovery’? In a sense it does, if you consider the iterative process of getting the highest priority business processes operational again first, then the next highest priority, and so on. However, in most cases, at the end of these iterations the aim is to get back the situation and the resources you had before the disaster.

That means there is no adaptation along the way, let alone any acceptance of ‘scope creep’ that other agile approaches allow. The recovery process has simply been carved up to make it serve the business better. Agile recovery, if it was done in the sense of agile development, would raise interesting questions about IT governance and the way IT affects business, as well as the way business should be driving IT. That may be a little more agility than some organisations can cope with at the present time.