On this occasion it appears that I believe in the wrong brand of agility, having spent my entire career adopting the most pragmatic methods that I could for delivering complex projects on shoestring budgets. I always assumed that this was an agile approach, in that it allowed me to respond rapidly to changes in requirements and to wrest effective code from the miasma of missing specifications that so often dominates large organisations. With these ad hoc methods and a little determination (alright, a lot of determination) I have built mission critical systems for a diverse range of clients, such that lives and billions of Euros of revenue have been literally dependent upon my craft.
Until a couple of years ago I was very proud of that track record. I had never met a project that could not be tamed, no matter how tight the performance constraints nor how poorly-specified at the outset. It was hard work, as my beloved and long-suffering goth_twiglet will attest, but like any master of their craft I felt genuine satisfaction with the work I produced.
But these last two years I have become mired in a world that I had previously never experienced: the world of corporate FUD. No company I had previously worked for had the resources available to get sucked into the black pit of highly paid consultants, outsourcing and technological panic that has dominated this period of my career and so when I heard anecdotes of the Great Methodology Wars I viewed them with the mild concern that citizens of peaceful lands feel for their war-torn neighbours, but in general I was too busy working to get directly involved.
I was agile and I was righteous and I was the heart of a creative maelstrom. Maybe not to the same extent as a Picasso or Michaelangelo at the top of their game, but I knew I rated up there amongst the great craftsmen and that gave me contentment.
How agile? Well there's nothing in the Agile Manifesto that contradicts my core principles or my daily working practices, and in fact I can think of no better way of achieving good software than by engaging in a dialogue with both the individuals who wish to use it and the problem domain which it represents.
But I'm starting to suspect that agility is not what this modern craze of Agile Methodologies is about. It's about conformity. Think like we think, join our religion, believe our holy words of power, fight the good fight against heretics and heathens and apostates. Be one of us!
Well apparently I'm both a heathen and an apostate. Having seen both SCRUM and eXtreme Programming up close and personal I find their holy words of power hollow, as flawed and corrupted as those of the Waterfall Methodology that they set up as their Unacceptable Othertm. Anyone who doesn't conform to this Dualistic Gnosticism finds themself out in the cold, their ideas ignored regardless their merit or of the reasoning behind them.
Apparently we apostates think too much. These Agile Methodologies are posited on the notion that the least effort only comes by leaving decisions until the latest possible moment, and then only solving the exact amount that needs to be solved at that time. After all, requirements might change and ergo requirements will change so acting any other way will cost resources. Forget the idea of looking at the bigger picture, of building a strategy, these methodologies are obsessed purely with tactics.
You don't have to look far in history though to see classic examples of how good strategy and indifferent tactics beat the pants off good tactics but indifferent strategy. This is the classic Pyrrhic Victory scenario, named after the King of Pyrrhus who fought Rome in a series of successful engagements only to find that his tactical brilliance counted for nought against the strategic advantages of his enemy.
But I prefer to look at the tales of Prometheus and Epimetheus (forethought and afterthought) as the real embodiment of the difference. Forethought involves pain, and often what it tells you isn't what you want to hear, but without it pain will still occur and you're left unprepared for the consequences. Agile has to be the agility of the foresighted if it is to be of any use, and yet these methodologies deliberately spurn the corrective measures that such foresight allows.
Why? Because requirements will change! But of course requirements will change, that doesn't mean that one shouldn't anticipate the direction those changes will take or seek to steer them in such a way as to maximise the gain from them. After all, a changed requirement is usually more an admission that not enough thought was applied to the problem in the first place than that the problem being solved has fundamentally changed: the latter in most cases will result in project cancellation, not a changed set of requirements!
There are flaws in my reasoning. There must be, otherwise methods that actually work wouldn't be sacrificed on the altar of methodology. And those flaws are doubtless human. Those flaws are FUD. The Fear that a project will fail, the Uncertainty over what it entails, and the Doubt as to whether it can be managed internally. Hence the hunger for clever words and rigid structures.
And as everyone in IT should have realised by now the stink of FUD is the worst stink of all...