Agile Insider reality bytes…

My Agile Awakening

I've considered myself to be an agile developer (albeit of the pragmatic/lazy style) since the very early days of XP and through the course of my career have had the opportunity to experiment with most of the practises and methodologies in various 'flavours', but it wasn't until I joined exoftware at the start of this year that I truly appreciated what agile truly means.

"Agile" as a term has been niggling at me for years, because it has no clear defining definition, leading to abuse where everyone can, and often does, claim to be "Agile".  Similarly, methodologies are extremely quick to jump on the bandwagon and claim to be agile (this is a topic for a future rant).

It is even more frustrating when there are so many purists out there advocating methodologies under the banner of agile.  I'm sorry, but this just  doesn't cut the mustard, if you're doing pure XP, you're an XP shop, but that doesn't necessarily follow that you're agile.  Yes, the technical practise may be extremely good, but that doesn't mean the process is...

In just a few months at exoftware I have been fortunate enough to witness how a truly agile team doesn't follow any particular methodology, but continually improves their own processes, borrowing practises and techniques from any methodology.  This sits extremely comfortably with me and confirms my beliefs of what agile is (mainly gleaned from Alistair Cockburn).  But the surprise wasn't that agile should be pragmatic in it's application, but that in order to improve your agile process the best techniques and practises are themselves agile.

As an example of true agile, is there any real/substantial difference between an iteration, timebox or a sprint.  I'm going to be happy to call this whatever the customer wants provided we can both agree a clear definition of what it means.  And rather than get into the whole what does done mean, lets choose a term that means something in the customers context.  Purists will have you release to production at the end of every sprint, but this will simply never fly for many large organisations (would you really want your online banking application being updated every 2 weeks with new features that had not been rigorously tested).  Similarly, will I get bogged down in ceremony about when to hold a retrospective, of course not, I'll use them whenever I feel there is an opportunity to learn or adapt.  I'll apply them not only to the deliverables, but also to the process being used to deliver.

The elitism inherent with many of the methodologies (and lets not forget the software craftmanship alliance) doesn't help with agile adoption, it just makes everyone else feel inferior...  Wouldn't it be great if the team that brought us the manifesto got back around the table and gave us something SMARTER (specific, measurable, acceptable, realistic, timeboxed, energising, rewarding) rather than a few open-ended, fluffy statements so clearly open to abuse...