When the word “agile” was plucked from obscurity in 2001 when the Agile Manifesto was published it was a very clever appropriation of a seldom used but rather descriptive word or concept.

Shortly “agile” became ubiquitous in the technology domain. Everything became agile, processes, methods, teams, developers, managers, companies, products etc. A technology company wouldn’t dare to exist without having “agile” sprinkled copiously everywhere on their website, marketing material, promotions, you name it.

I came to know about Agile in the early 2000s. Still, I didn’t pay much attention to it because from what I understood about agile it was very similar to the environment in my first company which was the worst company I ever worked for by far. Both, my first company as well as Agile, worked on the principle of chaos which was packaged as a fast scramble towards a slowly emerging goal which is not fully understood, ultimately unknown and is never reached. The difference, I came to understand later, was that in my company’s case the chaos was disorganized which was logical whereas agile tried for an organized chaos which was illogical or at least inconsistent. I was surprised then that whatever organization I went to in the last 15 years they always insisted on being an agile shop/group/team whatever.

So we have had over 20 years of agile, in the meantime, the cloud has become by far the biggest difference-maker in IT as it emerged at about the same time. We know what Cloud has accomplished, in fact it can be argued that the cloud is really the ultimate “agile” environment and so there is a logical connection between the Cloud and Agile even though the two developed completely independently. But what did Agile accomplish?

If we go by adoption of Agile everywhere then surely it’s been an unparalleled success, but maybe we shouldn’t. The fact that everyone does Agile tells us more about the sheep mentality of the IT industry than about Agile itself, i.e. organizations don’t adopt Agile on its merit but because “everybody is doing it”. Beyond adoption, there are no specific publicly available numbers that could tell us how the adoption went for adopters. Here I will have to rely on my own experience.

Every single client I have had in the last 15 years was Agile by their admission. That means that they all practised some kind of agile-based methodology, typically scrum. However beyond the methodology, there was not much that was agile about them. One really small company (about 10 employees) came as close as I have ever seen a company come to Agile but without the short release cycles (theirs were measured in months – fundamental Agile flaw), one smallish company (100+ people) was in the general vicinity of Agile again without the Agile releases. The rest, large, mostly multinational companies, didn’t come within a ballistic missile range of Agile and yet they were the proudest Agile disciples (in their minds obviously).

One bank had Agile almost plastered in their bathrooms but they had a very detailed SDLC with Agile sprinkled everywhere but describing a pure waterfall method. This caused problems and led to a shouting match between the developers who expected a finished solution design document and myself. I said that I was aware that the SDLC we used was a waterfall but since it was classified as Agile I held that my design document could never be finished because Agile said so even though it was finished based on the requirements at that specific time, which could change in the future. This is exactly where the problem comes in these organizations that use Agile simply to make them look current in their processes and approaches, they don’t understand that the language has consequences. If you turn your language into an Orwellian version where black is white and white is black then it’s difficult for all involved to get on the same page so to speak and you shoot yourself not just in the foot but in the head.

Now let me point out 3 basic fundamental flaws of Agile beyond the logical inconsistency I already mentioned that are completely overlooked by the zillions of followers:

First, the environment it relies on, small local teams, is only available in tiny software companies nowhere else. Even a mid-size company has teams spread in locations at least onshore and most likely offshore as well. They cannot possibly be/do Agile in any meaningful sense, it’s strictly logically impossible, despite what “scaled agile” companies try to market. Agile is tightly coupled and even synonymous with local, anything else is not Agile, no point in trying to square the circle. This is not a flaw per se, it’s a flaw in the sense that Agile allowed the bastardization of its philosophy without raising this as a fundamental constraint on Agile.

Second, the Agile philosophy explicitly allows for errors, bugs, and issues in software development, which can be fixed in the next release. How many companies, especially financial ones, are ready to release public software knowing that there are software bugs (unknown at the time of release) in the release, which will come to light in production? I have never met a single organization that understands this. If you are a fault-intolerant organization (whatever your business), don’t use Agile, which assumes faults. It’s just basic common sense. But don’t think that by not being “Agile” you prevented bugs, that’s not the case either. You prevent bugs by rigorous testing, the more testing, the lesser the chance of bugs and less agile, i.e. releases are slower.