Agile is great but don't bet lives on it, says founder
Subscribe now for $100 (23 issues) and save more than 37% off the cover price!
Get the latest news from Computerworld delivered via email.
Sign up now
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.
And some projects have a greater appetite for reduced quality in exchange for speed or cost of delivery.
You don't have to have trained in Agile to be able to deliver in an Agile manner.
But it has been entertaining over the past 10 years to see people ranting about "Agile spanks PBoK or Prince" ... I suspect they just didn't know how to blend.
Posted by a wise owl with battered ears and a few missing feathers ... at 10:59:59 on April 1, 2013
1. You do not have to have all the specs upfront, they can be created after the fact, once ideas are validated and polished by working prototypes.
2. One would need a longer stabilization phase, yes, but that does not require going Waterfall whatsoever. All one needs to do, it is to create a new branch in a source control for a released version and only make fixes there.
Than continue a normal Agile development in a main source control trunk. That is a standard practice in Agile anyway, but that stabilization phase needs to be longer, that is all.
In general Agile always ends for any released code in production branches, but continues in a main trunk, and that is the story for any Agile project regardless of its criticality.
Or am I missing something? (Arguments and disagreements are welcome).
Posted by Sergey Getmanets at 9:43:07 on March 29, 2013
Posted by Anonymous at 17:33:10 on March 21, 2013
Having said that, of course you still stand a much better chance of getting your people (muppets or otherwise) to produce something semi-decent if you're using an approach that focuses more on collaboration, embracing change and being flexible, and less on the belief that a) we should be punished for not being able to predict the future and b) shit never happens.
Posted by Russell Clarke at 18:51:35 on March 22, 2013
Posted by Anonymous at 12:36:30 on March 24, 2013
Posted by Anonymous at 14:13:57 on March 24, 2013
Posted by Anonymous at 15:55:12 on March 24, 2013
Posted by Anonymous at 19:36:07 on March 24, 2013
As for pharmaceuticals, they kill plenty of people without the aid of agile methods.
Posted by Marco at 17:33:01 on March 21, 2013
Posted by Anonymous at 10:40:44 on March 21, 2013