To no-one’s surprise, bad Agile is still bad

Over the past week or so, there’s been some noise about a new report, commissioned by consultancy firm Engprax for its book “Impact Engineering”, that compares the namesake Impact Engineering (think Waterfall) with Agile development practices. Given this context, it should be no surprise that the conclusion it comes to is that the former is more effective than the latter to an overwhelming degree. For example, see this article of the Register, “Study finds 268% higher failure rates for Agile software projects”. With the caveat that I have not read the book myself – it is not freely available, and I am not inclined to put money down when I already have reason to seriously doubt the methodology employed – I find several comments made by the author rather telling.

First, I would note that, as the Register has already observed, the report “could be seen as a thinly veiled plug for Impact Engineering methodology”, not that it seems to have impacted the rest of the Register’s article (although in fairness to the Register, it has also published this opinion article about the topic, which I largely agree with). Second, I would also suggest that 268% is such a ludicrously high percentage when it comes to project success that any sensible person should treat it with a good deal of scepticism to begin with.

More specifically, and more damningly, based on several direct quotes from the article I suspect that Dr. Junade Ali, author of Impact Engineering, either does not understand Agile methodology or is wilfully misrepresenting it. For example, they are quoted as saying that “65 per cent of projects adopting Agile practices [fail] to be delivered on time.” Not a good look for Agile, until you remember that Agile is partially defined by its lack of strict project deadlines, which it dispenses with in favour of continuous development. Regardless of how realistic or even desirable this structure is, any “Agile” project which fails to meet its deadline was, de facto, not truly Agile in the first place.

Dr. Ali also discusses the importance of “having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.” To me, this sounds an awful lot like continuous reassessment and sustainable development practices, that are – quelle surprise – core parts of the Agile methodology. They are included in the principles of the Agile Manifesto, no less.

There also appears to be some serious false equivalency going on. One of the most prominent findings of the report highlighted in the Engprax article is that having clear project requirements prior to starting software development resulted in a massive increase in the likelihood of project success. Yes, I’m sure it does! But despite the report’s suppositions, Agile doesn’t preclude having clear goals at the start of the project, it merely accepts the reality that those goals may (will) change as development proceeds. Pretending that Agile development is totally freewheeling and has no room for any requirements whatsoever is patently absurd. While it’s true that the Agile Manifesto prefers “responding to change over following a plan” it also clearly states that there is value in both. It’s also worth considering that according to this study, when “significant changes were made to the requirements late in the development process” the average project success rate increased by 7%. Seems rather unlikely, doesn’t it? Even in a thoroughly Agile environment, such changes tend to make things harder, not easier. I can’t help but feel this points to some deeper problem with the report’s methodology – it just doesn’t pass the sniff test.

At this point in the article, I was originally intending to say that the root problem with the study is that there is a stark difference between organisations that have claimed to adopt Agile practices and organisations that have actually incorporated the Agile methodology wholesale. I was going to continue that most companies that claim to adopt Agile development practices do so because they want the clout associated with the name rather than because they have actually bought into the methodology, leading to half-hearted implementations at best, and that this kind of thoughtless band wagoning usually ends up papering over deeper problems. I would have concluded that this report was essentially using Agile as a scapegoat for those problems.

This is all still true, but after further consideration I think what this report is actually doing might be even worse. It seems to be operating on an absurd, strawman version of Agile where basically reasonable values (like “responding to change over following a plan”) are interpreted in the daftest way possible (like not having a plan at all), while others are ignored entirely. All this in service of what else but making Impact Engineering seem more appealing. Frankly, if the best the latter has to offer are the amazing innovations of “having a plan” and “discussing problems when they occur”, I can see why this might have seemed necessary!

It’s not like Agile is perfect, or that it’s appropriate for every project. It’s not, and it isn’t. There are plenty of legitimate reasons to criticise the methodology and (especially) the ways it’s often practiced. But that’s not what this report is doing. Perhaps the book itself has more interesting things to say – but (especially) given the fact that it is billed as a “business novel”, I doubt it.