I had begun to hear the rumblings of agile in about early 2008. I remember having mentally brushed it aside as another one of those stylish just-off-the-shelf pieces of IT jargon that people in the industry identify themselves with for some time, before they manage to stumble upon the next buzz word. When, in a regular team meeting, I was told that the project I had been working on for the past couple of months was actually an “agile” one, I made no effort to register the piece of information anywhere in my brain for the excellent reason that it simply meant nothing to me. And I had my arguments. The technical challenges I used to perpetually remain buried under were so particularly engrossing that the “methodology” of project execution made no real difference to my life, whatsoever. All along, I’ve probably had an inherent natural ability to explain a complex technical situation to IT managers in a language that helps them assimilate and as long as I regularly kept passing elementary “updates” to those who mattered in organizations of various sizes that I have worked with, I didn’t really have to care much about the shop-floor level differences between agile or waterfall or whatever.
But the rumblings continued to grow into louder noises as the years passed. Soon I discovered it was not a bad idea at all to add the word “agile” into my CV. Regardless of whether it was looked at by a CV crawling computer or a hiring manager, this word would invariably end up churning a bit of a magic of its own. “So here’s a professional who has worked on waterfall, hybrid and agile projects” – this appended to whatever else I had in my CV would make two and two magically add up to ten. It turned out be a form of innocent legerdemain. The over-enthusiastic response to my CV would occasionally fill me up with guilt but very soon I would resolutely shake it off since I had not been lying at all. I had indeed worked on projects that were supposed to be agile and if that made my potential recruiters dance with joy, so be it. Post selection, the project I would begin to work on in my new assignment would also invariably be agile – probably of a more intense flavour but I would still not know the difference. Within weeks, I would predictably be back to my large monitors displaying green and black putty sessions, once again blissfully unaware that I happened to be part of modern new breed of IT machinery called agile where updates can (and probably must) pervade through an entire hierarchy of info-systems even before the job on hand gets properly completed. The morning stand-ups would happen with or without me depending on whether I cared to walk into that room on my way back from the coffee machine.
And now in 2016, I must admit I am really amused. The noise is deafening, I’ve spent the better part of my adulthood pursuing IT but fact remains I am still clueless about this thing called agile. In the past few years I have been a member of “ferociously agile” teams and am witness to 90% of my team mates spending 90% of their times updating online agile boards. In their little world nothing moves until it is captured on an agile board. No work is done outside of a “story”. But the shop-floor anvil continues to bear the same look. The real project work still happens to be down to a couple of brilliant technical guys who can’t manage to take time off their large monitors to go into those daily scrums. Most of the other team members seem to be acutely obsessed with agile activities – religiously indulging in sprint planning sessions, story pointing sessions, daily scrum sessions, retrospective sessions and the like. Going only by person-days spent, the bulk of the horsepower of agile teams seems to have been dedicated to managing the “flow” of information – true to the spirit of agile. Information “creation”, however, is still the sole ambit of a handful few who do the real work. For the ones who are used to actually breaking the back of projects, it still makes no difference. They remain oblivious to most of the agile drama, are still surrounded by large monitors displaying putty sessions and I can bet they still don’t know for sure what methodology their project is being run on.
My own experience therefore coerces me to conclude that agile is a farce at best and a sham at worst. People who can’t or don’t want to understand technology but who, for reasons best known to themselves, wish to keep belonging to the IT world invent new concepts to keep themselves busy – or at least to appear to be busy. Agile is just one of those concepts. I am convinced agile is a deceitful aberration that only adds noise to IT effort. I have never found it to present itself as anything other than a driver for the unnecessary micro-management and over-communication that some middle-level managers must sneak into projects to justify the salaries they take home. For the ones who really get the ball rolling, agile will remain a professional tax, a weird kind of an attempt to tame innovation into marrying robotic sprint cycles. No wonder agile is seen to be failing. It is failing because IT today is all about innovation and because innovation does not lend itself to water-tight sprint cycles. The real IT world will continue to be driven by leaders who can envision great ideas and by technologists who can implement them. That, in effect, is the “waterfall” truth about “agile”.
