Agile development: one of the worst concepts ever to exist in software

23 min readSep 9, 2021

Acknowledgements

I would like to thank Rob Pridham for his invaluable critique and subsequent discussion of the previous version of this article.

He showed me that I had not considered the relevance of Waterfall’s history and its perception in the minds of developers as much as I ought to, and that in order to argue the points I am arguing in this article more effectively, it was far more important to talk about the history of this subject (the transition of most development from Waterfall to Agile) than I had previously realised. You can find our conversation in the responses to this article here.

— — — — — — — -

I would also like to thank Cliff Berg for his insights, and for introducing me to Agile 2. Unlike the original Agile it is specifically not a framework, only a set of ideas, and after analysing it for myself I find it to be an exceptionally good concept. I have therefore updated the article to include Agile 2 as a possible solution to the problem of Agile. You can find our conversation in the responses to this article here.

· Terms and Definitions
· The history of Waterfall and the transition to Agile
∘ The role of CI/CD tools in moving to ‘Agile’
∘ Traditional Waterfall is blamed for things it didn’t cause
· Why, then, is ‘Agile’ worse than ‘modern Waterfall’?
∘ Initial context
∘ The Twelve Principles
∘ The Manifesto
∘ Agile’s additions to ‘small cycle development’ only did harm to project management
∘ The great irony of Agile
· Common logical fallacies in defence of Agile
∘ “We do agile with a little a, not a big A”
∘ “Agile says we prefer the things on the left, not that we don’t do the things on the right, don’t take it so literally”
∘ “It works because I’ve worked with it”
· Possible Solutions
∘ ‘Modern’ Waterfall (aka ‘no framework’)
∘ Agile 2
· Conclusions
· Other Articles

Terms and Definitions

First of all, the definitions of Waterfall and Agile, for the benefit of those who don’t know them, though probably many reading this article already will.

Waterfall: a development methodology in which each part of a project is completed in five distinct stages (making a “waterfall”).

Agile: a development methodology embodied in two ideas: the idea of doing projects in small, continuous cycles rather than one big cycle, and the Agile Manifesto.

In addition, there are a few extra terms to define here that will be used in this article.

“Traditional” Waterfall: The way Waterfall was implemented in times past, where a project would be one giant task with five stages. Infamous for being very unresponsive to change, difficult to manage, and horrible to work with — this is how Waterfall was almost always done in older software projects.
“Modern” Waterfall (aka no framework): Project management that consists of splitting a project into smaller projects, and that’s it as far as specific things go. Effectively, Agile without the Manifesto, or a ‘modern’ version of Waterfall that doesn’t do one big project slowly. You can call it anything you want, but it basically just boils down to having no framework.
Agile: The Agile methodology and manifesto. Differs quite widely in how teams choose to implement it, but in most implementations is simply “modern Waterfall” with varying levels of bad stuff from the Agile Manifesto put on top of it.

The aim of this article is to explain why “Agile” is not a good successor to ‘traditional’ Waterfall, and that it is in fact no more than taking a “no framework” approach and adding many bad ideas on top of it. It is time we removed those and decided to use either no framework or . In order to understand why this is, we must look at the history of software development’s move from Waterfall to Agile.

The history of Waterfall and the transition to Agile

For obvious reasons, this is not intended to be a complete or exhaustive history — but it is important to talk about some of it, as it is critical to why Agile came to be.

In older times — let’s say around the 2000s and before — almost all software projects were undertaken in the ‘traditional Waterfall’ fashion. This came with numerous huge problems — software is generally very large and very complex, making it practically impossible to split into five stages and not encounter unforeseen problems during them, often resulting in lengthy delays, expense and software that didn’t do what customers wanted it to do. It also made it very difficult to change the project when it was going on, as customers asking for change requests in the testing phase was effectively impossible and didn’t work with this methodology at all.

At this juncture, I should note that most projects in many other industries, many of which predate software entirely, don’t follow this pattern. Architects don’t build a 50-storey skyscraper and only test if it’s stable when the whole building is constructed; that would be madness (and if it wasn’t stable, it would probably collapse before completion anyway). Cooks don’t finish a recipe before tasting if it’s correct — they taste all the way through, because some things can’t be fixed at the end. If you need to caramelize onions for a recipe, you can’t do it after you’ve put everything else into your pot — you’ll never get the water out, you must do it and make sure it’s correct first before proceeding. Why, then, didn’t software take the same ‘small iterations’ approach before?

There are two reasons. The first is that software projects, unlike the above examples, are vastly complex and it is near-impossible to imagine the end result from the beginning or keep track of each layer during the process without tools (imagine a cook trying to keep track of a hundred different recipe stages during cooking; theoretically possible, but extremely difficult and impractical). The second is that the CI/CD tools were not available, or in their infancy depending on the date, making the first reason impossible to solve. This is crucially relevant because the advent of such CI/CD tools changed the viability of small cycles in software projects.

The role of CI/CD tools in moving to ‘Agile’

Today, things like automated unit testing, deploying to many servers at once, and managing large numbers of dependencies are made astronomically easier by CI/CD tools. In the past it was a painful, difficult, manual affair — imagine going into the command line to run all your unit tests every time you changed some code. It would take ages, it would be prone to errors, and this is on top of numerous other things such as more primitive IDEs and editors.

In all projects, irrespective of industry, there is an overhead associated with project setup, completion, etc. If you split a large project into many small projects, you generally amplify this overhead — something that also existed with software, not only because of the extra time but because of the difficulty of managing and testing so many small pieces of code at once.

Today we have excellent tools to deal with this, but in the times where traditional Waterfall reigned supreme, developers didn’t have them. Hudson/Jenkins and GIT both came out in 2005, Maven in 2004, Composer in 2012 — there were version control tools before that in the form of CVS and SVN, but CI/CD tools were generally either lacking or nonexistent. Trying to manage so many small projects as part of one big project, and develop and run unit tests on them, was an insurmountable administrative challenge in commercial environments back then.

As a result, the ‘Agile’ manifesto was simply unworkable in those environments. Now that we can automate unit tests, use dependency managers and have solid IDEs and other tools, it is far easier to develop in small cycles than it once was. The Agile Manifesto came out in 2001, around the time at which such tools were just beginning to form and be adopted; that, in my view, is no coincidence. After all, even in traditional Waterfall times, being able to do a project in small pieces would logically have been vastly preferable — it just wasn’t feasible.

This leads to a specific conclusion:

Traditional Waterfall is blamed for things it didn’t cause

Had Agile existed when CI/CD tools weren’t around, it would have been given an equally bad or perhaps even worse reputation than traditional Waterfall has now — it would have been nearly impossible to implement, cause huge amounts of wasted overhead time, and make projects astronomically hard to manage.

To be fair to those who had to work with it, it’s understandable that many blame traditional Waterfall for this — but logically speaking, it is really just a scapegoat for the lack of tools that were available at the time. The blame apportioned to it really doesn’t belong to anything — there was no methodology which would have improved the situation in any significant manner.

Of course, this isn’t to say that ‘traditional Waterfall’ would be good now; it’s a solution you would pick only when no better solution is available (due to the lack of tools). Now that we have the tools, a more modern Waterfall process is better. Even Agile is better now than a ‘traditional’ Waterfall model in the context of modern tools, but that isn’t saying much — a modern Waterfall would be far better than Agile is.

Why, then, is ‘Agile’ worse than ‘modern Waterfall’?

Initial context

To begin, some context: Agile is described in the Agile Manifesto, which can be seen at https://agilemanifesto.org/.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

With no hindsight whatsoever, it is easy to see that this was a terrible, terrible idea from the start. Anyone who has ever hacked together a project under pressure can see this: the entire concept of Agile is focused on pleasing the customer in the short term, at any price in the long term.

This has caused no end of damage in most software companies, because most software is not a short-term project; cutting corners and failing to document what you’re doing ends in disaster. Imagine building a 70-storey skyscraper floor by floor, and each time you build the next floor you hack it together as fast as possible and cut every corner; you end up with a building that costs billions to repair to keep it from collapsing every day, and which is far more expensive than if you had just built it correctly from the start.

This is an ubiquitous problem in software, and it is known as technical debt. To summarise the definition of technical debt from Wikipedia:

Technical debt is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.

I should note that technical debt doesn’t only include the cost of reworking existing components: adding new features to software with high technical debt often takes orders of magnitude more time and money than it should, since the code is often tangled up with dependencies that shouldn’t exist all over the place, legacy code that isn’t documented and only one person vaguely understands, and inefficient code nobody wants to put up the time and money to fix.

This problem isn’t unique to software: any business practice that emphasises toxic, short-term mindsets such as “finishing the product over doing it properly” or “the customer is always right” will produce the same disasters Agile does.

The reason why Agile is so bad in this regard is that the entire Agile Manifesto works to increase technical debt as fast as possible, and is oriented at short-term thinking only. Why is this?

Before we examine each line of the main Agile Manifesto, let’s look at a few of the Twelve Principles it contains.

The Twelve Principles

The “Twelve Principles” of Agile software development can be found here. Let’s look at some of them to understand just how they encourage technical debt and bad decision-making in teams.

Principle 1: Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Anything, ever, in business — that claims “our highest priority is to satisfy the customer” — is a recipe for problems. Customers rarely understand the inner workings of the product they are buying, so if your highest priority is to ‘satisfy’ the customer, quality and reliability are frequently overlooked. What does your customer know about internal code documentation, or your CI/CD tools, or the health and morale of your developers? Nothing, until it’s too late to do anything about it.

This isn’t unique to software. Companies in myriad industries, from food to cosmetics to jewellery all take advantage of this to sell low-quality or even entirely fake products, knowing that customers will frequently be unable to tell the difference — and if they do, it’s usually too late by then.

Software is an even worse problem for this, because in software we generally don’t sell one version of the code and forget about it. If the code is of low quality, because it was rushed to meet customer deadlines and not properly documented, it will make it even harder to meet the next release on time — and the next, and the next, resulting in more and more technical debt piling up. That isn’t in the customer’s interest or even in the company’s interest — it is only in the short-term interest of managers and companies wishing to look fast and responsive to customers, usually accompanied by constant excuses made up to explain why development takes longer than it really should due to technical debt.

Principle 2: Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Not only is this principle harmful, it’s not even true. ‘Harnessing change for the customer’s competitive’ advantage does not work: this principle makes the fatally flawed assumption that the customer’s competitive advantage is purely based on delivering software as fast as possible, and that no price will be paid for this. Delivering fast, rushed software to the customer may please them in the short term, but in the long term it will cause the software to become hard to maintain, slow to develop for, and expensive to change. That is hardly a competitive advantage for the customer.

On top of that, we can see again here the toxic, obsequious bow-to-customer-demands mindset here, which is good neither for developers nor for customers.

Principle 4: Business people and developers must work
together daily throughout the project.

To be fair, this principle is sometimes interpreted as a general “don’t let your devs be totally unaware of the business side of things” idea, but the “daily” part is problematic.

It is the job of the business people in the company to shield developers from constant customer demands, perform the negotiations and talks with the customer about what demands are feasible, and communicate them when that is finished. If your business people and developers are working together daily, it implies something is wrong with your methodology, as developers should not need to be aware of changing customer requirements every single day.

Of course, that’s not to say developers should never have to interact with customers or business people, but rather that it should not be their job to be the first line of contact or deal with customer requests that haven’t been otherwise considered yet.

Principle 6: The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

COVID has proven this to be nonsense; any team making use of tools like JIRA should have known this idea was nonsense long before now. There’s nothing wrong with face to face meetings and conversations, but they are often much more disruptive to workflow than text conversations. Many developers like to listen to music or otherwise focus on their work, and trying to both talk to people and remain concentrated on work is difficult.

The only thing face-to-face conversations enable here is faster transmission — much like phone calls, you don’t get the luxury of waiting to read the message at leisure, you must read and acknowledge it immediately. That does not make for a good working environment; it’s hard to concentrate if at any moment you’re going to be pulled out of your focus zone for a conversation.

Principle 7: Working software is the primary measure of progress.

Seriously? What kind of irresponsible developer would ever think this? It’s a ‘primary’ measure of progress if you never intend to change the software ever again after it’s finished. There are a handful of companies for which that may be true, but it certainly isn’t applicable in general.

Working software isn’t the primary measure of progress because that’s not what we are building as developers. We’re building software that can continue to be built upon for a long time. Imagine building a skyscraper, and the primary measure of progress is whether the next floor is up yet — rather than whether the building’s foundations are solid. Good luck with that.

Principle 11: The best architectures, requirements, and designs
emerge from self-organizing teams.

There’s no such thing as self-organising teams. All this really translates to is an abdication of responsibility on the part of the team leader —there is no actual benefit to it.

The Manifesto

Manifesto line 1: Individuals and interactions over processes and tools

It should be clear, logically, that this is bad in the long term. Processes and tools are documented, don’t rely on being in your memory, and when followed correctly have the same outcome no matter who performs them.

Individuals, on the other hand, will often leave the company and work elsewhere; interactions will be forgotten. When you have to ask Jane what John said about Mark’s personal rules for committing the code, there is a huge amount of potential for miscommunication and error. If Mark decides tomorrow to change how the code should be committed, who will know? What if he leaves the company? How do you ensure that a consistent process is followed? What about if new manager Sam decides the whole system needs to be changed to fit how they did things in their old job?

If you have a process, you don’t have this problem; this is why all competent, modern software companies use processes and tools, such as continuous integration, version control, continuous delivery/deployment, dependency management, and more. By using processes and tools, we can eliminate more human error and speed up development at the same time by reducing tedious work.

Manifesto line 2: Working software over comprehensive documentation

This is the ultimate “short term tunnel vision mindset” concept. Software is not like a piece of furniture you need to complete, ship, and forget about once it’s shipped: it is going to be constantly reworked, maintained, and extended.

When you combine prioritising “working software” with commercial time pressures, the inevitable result is poor quality code that has been rushed to meet customer deadlines. The attributes of such poor quality code have a multitude of terms, but here are a few of them:

Spaghetti code — poorly organised code that will need refactoring in future, and so long as it isn’t refactored all modification and extension of this code will take longer than it should
Dependency hell — when you don’t have time to update your project to work with newer versions of third-party libraries, this is often the result.
Bugs — errors in the code, ranging from minor issues to core failure.
Magic Numbers — doesn’t necessarily have to be related to numbers, but is a reference to including constants with unexplained values in the middle of code with no comments. Leads to nightmares later when nobody can remember what the significance of the constant is.

When you try to make changes or extend this code later, it takes much longer than it should, making your company uncompetitive and your software expensive to maintain. Documentation is one of, if not the most, important aspects of software in commercial development: since staff members change and documentation remains the same, it is the one way you can ensure that processes are followed, and that new hires can understand the code without relying on having enough old hires to train them (and lose their development time in the process).

Manifesto line 3: Customer collaboration over contract negotiation

This line has the same root problem as the other lines: mindlessly bowing to customer demands. While in theory, it doesn’t sound bad to ‘collaborate’ with your customer, in the commercial world this frequently translates to agreeing to anything your customer asks for no matter how ridiculous it is.

Here is a very good comedy (or painful, if you work in this field) video which requires no software knowledge, showing how blindly agreeing to customer demands is a terrible idea. It also depicts the rather depressingly accurate reality of how commercial meetings of this nature can sometimes go.

I’ve seen this happen quite a few times myself: I was working in a company where the higher-ups of another team agreed to a huge project contract to write software for another company. Managers, against the very clearly stated objections of the technical leads and senior developers in charge of the project’s implementation, agreed to the customer’s unrealistic 18-month deadline; the result was that the deadline was missed, and the company ended up suffering heavy contractual penalties for not keeping our end of the contract.

There are a few reasons why this happens:

Customers are, in general, very poorly placed to know what is reasonable in a software project timeline. How is a non-technical customer meant to know what a reasonable timeframe is for a given feature, or how a certain feature should be implemented?
It can be difficult to pin the blame of technical debt on a manager who caused it — many reasons can be given for projects running slowly, but managers are partially measured in performance on how pleased their customers are. As a result, they have an incentive not to care too much about informing the customer of technical consequences of their decisions (or discouraging bad ones), as by the time it becomes a problem it will be impossible to prove they were at fault.
Companies that charge on a time-and-materials basis (which is many of them) have no incentive to clean up their code, since if they have to charge the customer for 200 days of work instead of 100 days, the inefficiency of the code doesn’t matter; you’re still getting paid a constant amount per your staffs’ time. While this makes the company less competitive, this generally isn’t seen as important by managers in many industries because of vendor lock-in. Artists might well be familiar with this as a result of Adobe Photoshop; Apple is also a good example of a company well known to most people, for which vendor lock-in is one of their primary strategies. There are endless other examples.

Manifesto line 4: Responding to change over following a plan

There is a good reason people make plans: because planning leads to better performance. If you know what might happen, and prepare for it, you are better placed to react to it. If you react only when things happen, you have no time to consider your options and no time to properly form a strategy, and often end up implementing the fastest, easiest solution in the short term (which in software, frequently leads to horrendous problems in the long term).

‘Responding to change’ is simply a lazy way of dealing with change, instead of having a plan that accounts for changes. In most software projects, a certain amount of contingency time is added to the total estimate of how long the project will take, to account for the fact that things don’t always go to plan. More importantly, a proper plan already accounts for most plausible changes: if the customer asks for a very big change that wasn’t part of the plan, you take time to revise the plan. The customer should not be allowed to throw away the plan and rewrite it in the middle of a project on a whim (which is one of the many reasons for the existence of contracts).

Agile’s additions to ‘small cycle development’ only did harm to project management

At its heart, Agile can be said to simply be a practice of ‘being agile’: doing projects in small cycles or iterations, one piece at a time, rather than one big huge project. If that was all Agile was, I wouldn’t argue against it: I would embrace it gladly. Unfortunately, Agile — as the explanation above shows — added many unnecessary extra concepts which are harmful and unhelpful, and which can be seen in practice in many workplaces today.

This leads us to the great irony of the Agile methodology.

The great irony of Agile

Agile, despite being a supposedly different paradigm, is in pretty much all respects identical to ‘modern’ Waterfall + a toxic short term business mindset. In order to see this, let’s look at a picture showing Agile and Waterfall side by side.

“Agile vs Waterfall chart”, via SmartSheet.

This image perfectly sums up the toxic nature of Agile. There is practically zero difference between Agile on the left and Waterfall on the right in modern software development; the only real differences are wording and hype.

For example, when was the last time you saw an Agile project that didn’t do the same steps as Waterfall, in the same sequence? When did you last see a modern Waterfall project that refused to change requirements after finishing the requirements phase, and just carried on doing work the customer didn’t want for 12 months afterwards? Obviously, never. The only difference is that Agile “pretends” to be a continuous cycle, when in any competent software team, both methods are the exact same continuous cycle.

You might wonder, then — why do people care so much about Agile or tout it so much? There are two answers: business toxicity, and blaming traditional Waterfall for past problems. We can see the former reason easily by reading the ‘features’ of Agile in this image (and pretty much any other Agile project management description).

It describes “high-functioning teams” (of course, Waterfall teams are high functioning and collaborative too, and usually split into subteams in the same way). What the Agile paradigm really means by “high-functioning” is “high-burning”: teams that work far harder than they should to please their employer.

Again looking at the image, when did you last see an Agile project that had less focus on contract negotiation than a Waterfall project? Never. What kind of stupid business would not focus on legally binding contracts? It’s a smokescreen only — a pretense of being flexible, when it is in fact purely an excuse to push workers harder.

The conclusion here is that Agile’s ‘benefits’ are corporate propaganda — it doesn’t work differently to Waterfall. Any project manager with a functioning brain recognises the value of not having gigantic projects; even cognitive behavioural therapists apply this to human psychology. The concept of not having giant, immutable projects, but rather many gradual projects that make up a large project, predates software development. Waterfall in any competent company already does what Agile claims to do, without doing the short-term thinking and ignoring worker health parts.

It is very understandable that developers who had to work with it often blame traditional Waterfall for past problems — it was a very poor system, but that wasn’t because the system itself was bad. Waterfall was only bad back then because the tools to do it properly — i.e. splitting a project into many smaller waterfalls — were not around.

Common logical fallacies in defence of Agile

Sometimes, when discussing Agile with other developers, you will hear cries of:

“We do agile with a little a, not a big A”
“Agile says we prefer the things on the left, not that we don’t do the things on the right, don’t take it so literally”
“It works because I’ve worked with it”

Each and every one of these is complete bullshit. Let’s examine each in turn.

“We do agile with a little a, not a big A”

This is just about the worst corporate propaganda lie ever. Imagine thinking that changing a letter meant you are suddenly doing a different paradigm; no you aren’t. It’s the same paradigm with a better PR image.

What people really mean by this is that they’re “doing Agile in a less strict way, taking it less seriously” — and this is literally never true. Commercial pressures invariably make it get taken seriously; the only difference between little a agile and big A Agile is a different ASCII code.

“Agile says we prefer the things on the left, not that we don’t do the things on the right, don’t take it so literally”

I’m universally convinced that people who say this fall into one of two categories:

99% of the time: they’re completely incompetent and/or have never worked in a commercial environment in their lifetime
1% of the time: they hit the holy grail and work for a software company that actually has good corporate management

If they’re in the 1%, good for them — let’s hope the industry changes so everybody can have the holy grail. Those in the 99%, however, are spouting the most stupid argument it’s even possible to spout, which is really saying something.

Let’s take one of the Agile manifesto lines as an example, because they are good measures of how ‘seriously’ a company takes Agile.

Responding to change over following a plan

Companies that claim to practice ‘Agile’ do one thing very well: they bow to practically any customer demand. Companies like to keep customers; managers, therefore, like to give the customer whatever they want. Agile encourages this, and if you find me an Agile workplace that “followed the plan instead of quickly scrambling to respond to customer demands in an obsequious and chaotic manner”, I’ll find you the holy grail. I’m sure one or two exist, but I’d have a hard time finding them.

“It works because I’ve worked with it”

No it doesn’t. This almost invariably translates to a few logical fallacies:

“I worked in a company that called itself Agile but actually was very Waterfall-like, so I’ve decided Agile is great”
“I didn’t see the huge problems Agile caused in my team because they weren’t on my personal desk, therefore Agile is great”
“We finished the project and had a champagne party, technical debt and long-term considerations don’t exist, therefore Agile is great”

Possible Solutions

I see, so far, two possible solutions to where we should go after Agile.

‘Modern’ Waterfall (aka ‘no framework’)

Ultimately, it is arguable that we no longer need a framework for software development. If we remove the principles and values of Agile, we are left with this: a simple system whereby we split projects into smaller projects, so that they are more easily managed and changed.

This is one way we can excellently move on from Agile, but there is another.

Agile 2

Agile 2, which began late in 2020, is — to me — a very promising successor to Agile, that specifically states itself not to be a framework (perhaps as an acknowledgement that a framework is no longer desirable, since they are prone to being misused). It is instead a collection of ideas; the difference is that Agile 2 does not state priorities or give any impression of one thing being “more important than another” as the simplistic Agile Manifesto values do.

The website for Agile 2 can be found here.

I took a fair bit of time to read through the values and principles that Agile 2 proposes, and I think it is fair to say that they are very good foundations for developing good software. This is for several reasons:

Firstly, Agile 2 does not give business instruction. The short ‘values’ of Agile 2 do not give a priority to one side over another, unlike the original Agile Manifesto, and they explain themselves instead of being short one-liners that can be easily misinterpreted or misused.

Secondly, the principles of Agile 2 are very detailed. While no set of ideas can be described as “not misinterpretable”, I think it easily passes of the bar of being detailed enough that it couldn’t be easily misinterpreted by accident, and a person trying to maliciously misinterpret it would have difficulty given that one can look to the detailed text to show why the malicious misinterpretation is wrong, rather than in Agile where any disagreement tends to devolve into one person’s word against another’s in the absence of any other resolution. In addition, there is a lot of detail in Agile 2 about precisely what constitutes any given concept — such as e.g. business value — so that it is much less open to interpretation, and more understanding of specific requirements.

Thirdly, and most importantly, Agile 2 specifically brands itself as, and associates itself with, the concept of not being a framework. While this doesn’t sound like a major point, much of the original Agile’s problem was that it was seen almost like a holy religious book — a set of laws never to be broken, which contributed to a completely splintered community in terms of how it was interpreted. Agile 2 is more comparable in my view to an academic text — it lays out its reasons, and individual developers and teams are free to question and discuss them, something which in Agile was effectively pointless (nobody could ever categorically prove the intent of the Agile Manifesto, because it was so short and vague, which also made it impossible to prove it ‘wrong’ for a long time. Agile 2 nails its colours to the mast in its detail, so it doesn’t have that problem.)

As a result, I think Agile 2 would also be an excellent way for the development community to move forward from Agile.

Conclusions

It is fair to say that Agile was better than the traditional Waterfall methodology, but it was nonetheless a bad successor that did not need to be there; ‘modern Waterfall’, or whatever you would prefer to call it, would have been far better. I consider Agile “one of the worst concepts ever to exist in software” for a good reason: there was absolutely no cause or excuse for deciding that developing software in small cycles needed a whole bunch of harmful, unnecessary clauses in it, and those clauses have done huge, avoidable damage.

Nothing stops software from being done in small iterations, as Agile does, without the Agile Manifesto’s harmful additions, and the unnecessary prioritisations it makes. We would be far better off to drop the term ‘Agile’, as even the name itself does not do any favours in commercial environments.

It is in my view long past time that Agile fell out of favour; the two solutions above are the ones that I believe to be best for how we should move past Agile.