Having worked for more than a year in an environment ‘infected’ by Agile virus, where dogmatic managers don the role of Agile evangelists, preaching the Agile religion – blessing the faithful souls and forcibly converting the other hapless infidels, I have come to believe that Agile is not the way to go; for, the reasons are one too many. Wary that I might incur a curse from the Agile priests, I venture out to indulge in blasphemy.

Agile is all about developing software iteratively, with iteration spanning a few weeks and involving the whole community (clients, who consume the deliverables, testers, documentation writers, UI designers…), throughout. Making frequent deliveries is meant to add value to the customers and somehow enable you to deliver in ‘Internet Time’. Further, it would also enable the team to cope with changes in requirement, and in minimizing the risk.

No Panacea
This is like the software development conundrum has been cracked; “Software development is easy! Huh?” Perhaps, they have happily forgotten or never heard about the ‘No Silver Bullet’ prophecy.

Of course, the whole idea seems noble. But, that iteration thingy is nothing but a small project in itself – starting from requirements and design, to coding and testing, and making a full-fledged release (with all that bureaucracy involved). It does make life more miserable, for one has to bear the stress that is involved with an official release. It is much more than just checking in code, and running some test scenarios.

Mad rush
Quicker releases need not necessarily imply qualitative releases. To satiate the ever-demanding customer and the greedy management, iterations are packed with new features to be delivered; and, resolving bugs take a back seat. Again, the hapless developers come under heavy pressure.

It is a mad rush out there. These companies have become factories producing sprinters that are just happy to run, and run faster. The only purpose of their existence is achieving the iteration milestones. Nobody has enough time to mull over various design alternatives, let alone writing a spec. At any point of time, a kind of reply would be “Well, that is how it would eventually be, an independent adaptor. But, for the current milestone, such a dependency would be acceptable. We are yet to figure out how to realize interaction with such an adaptor”. Things are never in a reasonably presentable shape.

Chaos Reigns
Come next milestone, the whole idea would have changed. Adaptor concept is now replaced with a full-fledged pluggable framework - A new layer of abstraction that is generic; for, it can allow third party tools to plug in as well. Isn’t that cool? Obviously, this means, trash all that you have done until now and write more code for this coolest feature. Yeah, you are privileged enough to be working on coolest framework!! Needless to say, this would eat away few more milestones in the schedule. In bigger projects, such scenarios show up almost every milestone, messing up the whole thing. Chaos rules!

Couple this style of development with globally distributed projects, and it’s an implosive mixture, capable of bringing down the project or transform it into a treacherous beast. Of course, each of these sites would like to be credited with the delivery of the coolest feature, and on time. There is more to it; teams are keen to prove they are worthy and that they can design ‘independently’. Why else do they need those fancy-titled architects for? Yet, nobody has that single big picture. All in all, the conceptual integrity takes a beating. Naturally, the seamless user experience or quality of product suffers.

There is every chance that one of those Agile bigots around might stumble upon this article. Fearing that, they would barge in anytime, fully armed, and that I have incurred their wrath, am reserving the rest of my Agile thoughts for some other time.

Shhh!! Time to put on that Agile-loving mask and wear a friendly smile! :-)

"... For example, one friend of mine was a cheerful catalyst, a bouncy cruise director who motivated everyone else when the going got tough. He was the glue that held his team together. But he tended to get negative reviews, because his manager didn't understand his contribution. Another friend was incredibly insightful strategically; his conversations with other people about how things should be done allowed everyone else to do much better work. He tended to spend more time than average trying out new technologies; in this area he was invaluable to the rest of the team. But in terms of lines of code, he wrote less than average, and his manager was too stupid to notice all his other contributions, so he always got negative reviews, too. Negative reviews, obviously, have a devastating effect on morale. In fact, giving somebody a review that is positive, but not as positive as that person expected, also has a negative effect on morale."