Opinion You've got to be light on your toes to keep up with Agile. Some say it's the inherently right way to do software. Others call it a cult, overblown and misleading. One way to tell would be to compare Agile and non-Agile project success rates, and that's just what consultancy Engprax did.

The result: at least according to the study, Agile projects fail exactly 268 percent more often. Not 267 percent or 269 percent, and how can you argue with precision. 

This would seem to move the needle towards a perception of the methodology as a type of culthood, and here Agile hasn't always helped itself. The basic idea is that software projects are too complex to manage by creating a precise plan and sticking to it, so lots of feedback and ability to change has to be built in along the way. Agility, in other words. Sounds sensible enough, but the creators of the idea spiced it up by writing the Agile Manifesto.

Manifestos are manifestly dangerous. They start out by describing how a new way of doing things can solve old problems, which is often necessary. Once the new ways are in place, though, the nature of the problems is going to change - and manifestos rarely change to match. There is much irony in the Agile Manifesto preaching pragmatism over prescription and openness to change over rigid adherence to overspecific plans.

To abuse a saying commonly used of politics and religion, Agile's problem isn't Agile, it's the people who believe in it. To be more specific, it's the people who believe that adopting a new, preferably fashionable methodology, can by its mere presence fix what went wrong in the past. Yes, our projects were delivered late, over-budget and parodies of what was promised, if they were delivered at all. Can't happen with Agile, it fixes all the problems. 

It can and doesn't. Naughty Agile.

Look at this from the viewpoint of the people delivering the projects - those charged with putting finger to keyboard and making code happen. They have tasks to do, goals to meet and resources of time and other team members to help. They want to do a good job: there is little as satisfying as being a part of success, and little as dispiriting as being on Team Fail. Especially if it was clear what was going wrong and nobody had the power to change it. All this is true regardless of methodology: it's how a methodology helps or hinders the individual that makes the biggest difference. 

The waterfall principle which provoked the rise of Agile had plenty of structural problems that made people party to failure without a chance to fix it. Detailed specifications turned into detailed schedules of highly compartmentalized tasks look great to management. They are also inherently vulnerable to the unexpected discovery, the incorrect assumption, and the change in circumstances. With little feedback other than cascading slippage and few remedies other than big reboots, the individual developer is locked in the cells of the project chart. You can make things worse, you can't make them better. 

Agile sees all that, and it feels your pain. Design and specification documents are functional breakdowns of the essential components of a project, not necessarily detailed blueprints. Get the skeleton up and running, compare notes with others as you go along, and problems will be spotted much sooner - and everyone they touch can be part of the solution. Which is lovely, if that's all you've ever known and you understand the disciplines underlying the ideas. If you're writing a component that has to stand up before it's finished, the target is still to make the finished component on time, not to forsake that for the intermediate stages. If the pressure's on you to do the wrong thing, or there's no guidance in how to do the right, it won't end well. Demotivation once more. 

As for letting the code lead the documentation and interacting across the project, these can and do go horribly wrong if you don't see them as tools in their own right with their own rules to be applied successfully. You can't just take a group of people used to working under one ill-fitting methodology and force them into another.  If the company culture has been top-down management and plans handed to the tribe on tablets of stone, handing out another set of Thou Must and Thou Must Not will go about as well as things did in biblical times. 

It may be true that Agile projects fail twice as often as others, although one study is just one study. That may be because the Agile Manifesto correctly identified the problems but didn't think through the implications of its remedies.

It's more likely that Agile's bad rap comes in the same way that Macbeth has become the "unlucky" play in theater lore, where even to say its name brings calamity. That happened because Macbeth was seen as such a guarantee of success that theaters in trouble put it on as a last ditch attempt to stay afloat. This rarely worked, so the play became associated with failure.

And so it is with the huge slapdash edifice of corporate IT development, with so much cultural and managerial inertia that change will come not with new ideas, but the aging out of the old guard.

That, perhaps, we can find out, not by counting failed projects and grouping them by methodology alone, but by what sort of projects, what sort of organizations and what sort of people were involved.

Not for the first time, the IT industry stands desperately in need of serious analysis as the group of people with the most power over the future of us all and which is under the least amount of scientific scrutiny. Perhaps we can write that up as a manifesto. ®

https://www.theregister.com//2024/06/10/agile_opinion_column/