Agile study backer talks catastrophic software failures

Interview You can have your software fast or in a state where it won't blow up in your face. But getting both at the same time in an era of layoffs and restructuring is, at best, challenging and, at worst, impossible.

So says Dr Junade Ali (pictured above), who spoke to The Register in the wake of the furor generated following a study that found that all was not well in the state of Agile.

A lot of the Agile fundamentalists will argue that user stories are sufficient. These essentially just describe functional behavior, but they lack a generalizable specification or nonfunctional requirements

Ali points to research (commissioned by himself) that shows British adults would much rather software worked properly than was chock full of new features. "They actually rank getting the latest features as quickly as possible as the least important thing for them when using computer systems.

"The public were most likely to agree that data security, data accuracy, and no serious bugs were the things which matter to them."

According to Ali, this stands in stark contrast to several metrics used in DevOps and Agile methodologies. "They're very much about the speed of delivery of software on one hand, and then on the other hand, the speed of resolving issues."

It has been a golden era for anyone covering outages, as banks, retailers, mobile networks, and cloud vendors have all been hit recently, something Ali attributes to pushing out updates with inadequate reliability. He goes on to worry about the impact incidents, such as the recent CrowdStrike problems, will have on the trust of users.

After all, legitimate security patches arising from 0-days and the like will need to be installed as soon as possible. However, according to Ali, a loss of trust could result in user resistance.

Ali has quite the library of doom and has written extensively on the topic, covering multiple engineering catastrophes over the years. Yet his take is that the problem does not necessarily lie in the testing process: "What you often find is that the typical catastrophic computer failure starts with there being a flaw in the initial requirements engineering process.

"And then what happens is that it cascades because often those issues are covered up or engineers won't feel as if they're able to be safe to raise the alarm. And so that snowballs throughout the entire software development process until a catastrophe happens."

CrowdStrike is an example of a disaster so visible that trying to quietly cover it up was simply not an option.

Frameworks and processes

Is this the fault of Agile? Engineers being afraid to speak up was certainly not what the authors of the original manifesto had in mind. However, the ideals of the original Agile Manifesto have been eroded over the years as frameworks and processes have sprung up around them. As Jon Kern, one of the authors of the manifesto, put it, "There are some misconceptions about the difference between doing some Agile framework and being Agile."

Ali warmed to the theme of capturing requirements as key to dodging a potential disaster and testing what needs to be tested.

"Testing is kind of one of those tools that are there, but in order for testing to actually be able to work at all you need to know what you're testing. So you need good requirements to outline the non-functional requirements that are there."

Such as reliability.

"The interesting thing is that a lot of people, I think, in the Agile community, a lot of the Agile fundamentalists will argue that user stories are sufficient. These essentially just describe functional behavior, but they lack a generalizable specification or nonfunctional requirements."

"And so I think that's one of the key flaws. When you end up looking at the most dogmatic application of Agile, we just have user stories, but you've lacked that generalizable specification."

Kern would disagree and argue that foregoing clear requirements is "just silly." A glance at the Manifesto for Agile Software Development places value on both working software and comprehensive documentation (although the former is valued more than the latter).

The publication of the Agile Manifesto dates back to 2001, and Ali is most interested in its evolution over the years. Ali says he is least concerned about project management so long as a strong requirements-gathering process complements it.

• Fragile Agile development model is a symptom, not a source, of project failure
• Study finds 268% higher failure rates for Agile software projects
• This typo sparked a Microsoft Azure outage
• CrowdStrike meets Murphy's Law: Anything that can go wrong will

For software engineering, however, things are less rosy. He points to an interpretation of DevOps where issues don't really matter as long as the system recovers from them, and velocity and quality are never in conflict. "This has led to absolutely catastrophic outcomes in the past."

However, it is organizational transformation, where a methodology and mindset branded as "Agile" is applied across a business, which is where the wheels can really come off. Ali points to transformations attempted without the informed consent of the individuals concerned or where a company might have been sold on a false narrative.

"There aren't universal solutions where you can have everything at once, and you can have your cake and eat it. But that's often what's sold by these kinds of transformation methodologies."

As budgets get ever tighter, the lure of a silver bullet that can offset layoffs and a lack of resources with a methodology that claims a company can do "more with less" is alluring. However, from the perspective of both Jon Kern, a co-author of the Agile Manifesto, and Dr Junade Ali, a critic of Agile methodologies, assuming a project and organization's issues can be covered with a sticking plaster marked "Agile" is at best shortsighted and at worst, catastrophic. ®