Agile is great but don't bet lives on it, says founder

Agile development specialist says that when reliability is more important than flexibility its best to opt for traditional methods

Agile development specialist Alistair Cockburn acknowledges “agile is not for every project, but the hard part is to name which projects it’s not for.”

Broadly, anything where a need for 100 percent reliability exceeds the need for flexibility would be better off using traditional methods with a rigid specification defined up front and adhered to, he told Computerworld, in a brief interview after a presentation to an audience from the Institute of IT Professionals in which he repeatedly extolled the virtues of agile development.

Cockburn is one of the initiators of the agile software development movement, having helping write the Manifesto for Agile Software Development, in 2001. He developed the Crystal family of methodologies and co-founded the International Consortium for Agile in 2009.

In trying to characterise the choice of agile against more rigid approaches, Cockburn sets out a graph of the number of people that have to be coordinated in the development process against “the number of people who will die if something goes wrong.” Agile is ideal for projects at the bottom left of the graph, “small projects, web projects, exploratory projects, agile is fabulous; it beats the pants off of everything else - but for NASA, no.” For space-shuttle development or pharmaceuticals – “there will be lots of people involved and very high criticality; they don’t care about agile; they don’t care about the capacity to change stuff all the time. They want this thing to be defect-free. The priority of ‘gee I can change my requirements’ is much lower than ‘I don’t want people to die’.”

He also factors into his scale the probability of loss of “essential money” and “discretionary money” as a consequence of malfunction and, on the lower part of the scale “loss of comfort”.

In some development processes, for example, development of software for mobile phones, agile is ideal at the beginning, where ideas are not fully formed and “there’s a lot of discovery”, Cockburn says. But later, when the product nears release, the software needs to stabilise so it can be exhaustively tested.

Not many people in the agile world talk about when is the right time to make that transition from an agile environment to a greater concern with freedom from defects, “where you take more time and want less change”, he says. In a comment that might resonate with those suffering from lack of discretionary or essential money as a consequence of the Novopay mishaps, Cockburn says the big government agencies and contractors to government, “need to know agile, and they need to know when to use it, when to dial it up – but also when to dial it back down again.”

In his main presentation, he was much more gung-ho on agile, pointing to seminal studies of the conventional methodologies, that demonstrated a high rate of failure. Agile, he maintains, can be objectively demonstrated to be overall more successful than the older approaches.

He agreed with Rob England, author of the IT Skeptic blog, that top-flight agile development needs a “Renaissance Man” combination of talents; asked how that would scale in the face of a growing requirement for developers, Cockburn contends agile techniques as a general rule don’t need to be super-efficient, just better than the alternatives – and they’ve achieved that.