« Welcome to the MWD team blog | Main | OASIS' SOA Reference Model: not just for propellerheads »

Who wouldn't want to be agile? The word itself suggests being lean, lithe, quick-footed, having all the moves and the instinct to use them. 'Agile' is hip, it's sexy, and unsurprisingly, ever since the term has been applied to software, it's had plenty of positive press both in the media and in the IT department.

Software methodology has always gone in waves, flip-flopping over time between structure and flexibility. So waterfalls gave way to spiral development models, and V-lifecycles faced off the new freedoms of Rapid Application Development, itself re-iterated as the more constrained Dynamic Systems Development Method. This cycle continues, with programmer’s programmer Kent Beck cutting the Gordian knot of convoluted software processes, slaying the dragon of overbearing management and picking up a lucrative publishing contract on his way down the mountain. Others have jumped on the 'agile and adaptive' bandwagon – indeed, some claim to have built it, how else would Mt Beck have got up the mountain?

It was ever, and it probably will ever be, thus. A good illustration of such thus-ness is the current debate around exactly what is agile development. More than once recently, I’ve heard the remark, “That’s not real agile.” For perfectly valid commercial reasons, of course, it is important to be seen as agile; equally, this can be upsetting to those who see their own, principled approaches being sullied by unscrupulous marketers. Indeed, the DSDM consortium is insisting that it is agile too (or indeed, “an enterprise-ready wrapper for agile practices”; “Nah, that’s not agile, its more adaptive,” others will say. How the winter evenings will fly by.)

Don’t get me wrong, I’m all for agile – whatever it is. But that’s an important ‘whatever’. It s quite easy for an organisation to say, “we’re agile,” However the reality could mean, “we’ve adopted the agile manifesto and its principles to the letter, and everyone in our dynamically organising teams can quote them from memory”; or equally, “we’re chaotic and we don’t want a formal development process so we’ve chucked a few trendy terms in the pot and we’re using them to fool our not-that bright IT management.” Even if the latter is not the case, how can businesses that had their fingers burned with RAD be sure that agility is delivering the goods?

Simply that, in fact – whether it’s delivering the goods. But what criteria to use for delivery? It is one thing to update a release of software, but quite another to make a positive difference to users. For commercial businesses and public organisations, the single criterion that makes any sense is, “does the delivery help the organisation in business value terms?” This can be couched in a whole variety of ways – user productivity for example, staff well-being and customer satisfaction – but again, all of these should be supporting the overall financial health of the organisation – either making or saving money – or they are missing the point: this is as true for public as private organisaitons.

The second factor involved in delivery however, involves the longer-term, sustainable benefits of any deployment. It is one thing for example to deliver the most basic of Web sites in ten days, which enables a company to start selling its products or reporting to its clients. As the company gets successful however, is the Web site going to keep up? Are the costs of any workarounds going to grow, such that in time, they outweigh the benefits? Will the increasingly demanding client base stop seeing the site as a useful tool, but more as a bottleneck? Everybody has their story of how the prototype became the production version – not the kind of early delivery that anyone would advocate, given the choice. If an organisation is going to deliver functionality early, not only does it need to add value at the start; also, later deliveries should work to shore up any kludges at the same time as adding to the functionality that’s already been deployed.

Agility doesn’t only exist within a project; it should also be present without. Perhaps the greatest test of agility of all, is the ability of a project to recognise when it is no longer able to add value, and has therefore reached the end of its useful life. Agile indeed, will be the developer who recognises his or her skills are no longer necessary on a project, and who is prepared to reskill or make themselves redundant as a result. It’ll take more than a methodology to tell them that.

Posted by joncollins in Software Lifecycle |Digg This|Add to del.icio.us

Trackback Pings

TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/771