Agile manifesto is problematic

After reading the agile manifesto, I felt like it is too one-sided and imbalanced, it gives too much importance to some aspects of software development and belittles the other.

The stuff they give prominence to isn’t any extraordinary new age rocket science (though the practitioners of agile try very hard to pretend like that!). Its just some basic common sense stuff such as:

Working software over comprehensive documentation

Should it really take a genius to tell you that? The working software funda has been going on since Windows-95 (and even earlier), long before these agile pundits had started going to their schools. I never had to read a single line of documentation when I started using Windows-95 for the first time.

Even before Windows-95, they invented the concept of man pages in Unix which allowed for component specific documentation (manuals) to be embedded as an addon to Unix itself. And this happened in Bell Labs way back in 1960s, long before these modern agile pundits were even born!

Coming to the second point, the stuff that agile tries to discard and throw away are some hard learned lessons which helped the humankind to reach the industrial age.

Individuals and interactions over processes and tools

Again, nobody is denying the importance of human interaction, its a basic common sense thing that humans have been doing since the stone age and will continue doing till eternity. But belittling processes and tools? That’s preposterous! If anything is preventing the modern economic and banking system from falling apart, its processes and tools. If the growth of top MNC companies and the industrial revolution is still continuing to hold, its again thanks to processes and tools. Without processes and tools, humanity is back into the stone age (or perhaps the bronze age, but doesn’t really matter).

The point is that both human interaction and processes have their importance in economic growth and development, and more importantly, this is a very basic or common knowledge at this point, we don’t need agile pundits to teach us these basic things.

Yet another gem from agile enthusiasts:

Customer collaboration over contract negotiation

Can you even imagine this to be an X versus Y thing! Collaboration with the client and negotiation of an IT contract are totally different aspects of the business and both are important.

The former is mostly technical and happens between the programmers/designers on outsourcing company’s side, and the users on the client side. Whereas the latter happens between sales and procurement heads of the outsourcing and client companies respectively (in some rare cases, the CFO/CEO may be involved).

Again, a very basic thing which should be in the first year MBA syllabus! Now, let’s expose the final aphorism of the agile pundits.

Responding to change over following a plan

As I’ve recently written about this in a DEV.to article, the agile enthusiasts always live in the delusion that software was never made in a dynamic or changing environment before they started treading this planet. The iterative model, a variation of water-fall model of development, was practiced since decades before the agile wisdom was being sprouted by these people.

All in all, the agile manifesto brings nothing new to the table and desperately tries to present the already proven conventional wisdom and common sense things as if they were a new concept or methodology they’ve invented from scratch. This is just absurd and ridiculous, and people shouldn’t fall in their trap.

[ architecture  productivity  software-engineering  ]