Does Agile Development have a place in your organisation?

‘Agile’ is such an uplifting, positive word, its no wonder everybody wants to use it. Manufacturers want to be agile, businesses want to be agile, and indeed, IT wants to be agile. In this latter context the term has been adopted to define a group of software development approaches that are, of course, agile. But beyond a general warm feeling about building more flexible systems faster, what exactly does agile development bring to the party?

We should start by being a bit more precise about Agile Development. Historically speaking, software development approaches have tended to fall into one of two camps – ‘structured’ and ‘the rest’. Those familiar with the developer side of the house will recognise the more structured approaches, which generally involves:

• Starting off with a requirements document and/or functional specification

• Doing some kind of software design

• Programming against the design

• Integrating and testing, first in parts then as a whole

Fair enough, perhaps. But, the detractors say, such approaches are far too slow and unwieldy: the rationale is that by the time the resulting two-year development cycles are complete, the world (and indeed, the system requirements) will likely have moved on. And so has evolved a counter-culture of alternative, ‘agile’ approaches, which tend to share a number of characteristics – proactive liaison with users, and frequent delivery of working software, being among them.

The value of agile approaches is clear in principle. When we undertook some research (https://freeformdynamics.com/software-delivery/agile-development-is-it-right-for-you/) into agile development earlier this year, we found there were certain types of project that would benefit from Agile approaches over and above traditional, structured approaches – notably those which have faster changing requirements, and for which rapid delivery is a priority.

All the same, there is no massive perceived difference in the quality of results from Agile projects, nor their timeliness, when compared to structured development projects. Rather, benefits are articulated in terms of increased collaboration within development teams, better awareness of timescales and indeed, more highly motivated developers.

What of the downsides? For a start, agile approaches are not just something you can pick up and run with. There is little room for error: timescales are divided into variously named short periods (e.g. ‘scrums’, or ‘timeboxes’), which are kicked off with a prioritisation exercise as to what is to be delivered, and finished off with a delivery. If something goes wrong, there can be a domino effect on other parts of the project. To all intents and purposes, agile approaches can be intense and rewarding, but the one thing they are reliant on is a level of structure and co-ordination.

Perhaps it is for this reason, one of the main criticisms of agile approaches is that they can’t scale. No doubt the advocates of agile approaches are reading this and shaking their heads – but given what we have just said, it is unsurprising that the challenges of keeping things going can become greater as projects get bigger. According to our research, having good communications is absolutely the key success factor for scaling agile projects beyond tens of developers.

While neither type of approach can claim to ‘win’, they both hold their own – and they certainly wipe the floor compared to less formal approaches. So, we have a situation of ‘horses for courses’. There are undoubtedly places where agile approaches fit better than more traditional structured approaches. However agile development is as much about a culture change as anything, however, and should not be undertaken without due care, indeed training and mentoring can help a great deal here. Agile is more a series of short, carefully linked steps than a journey, and it is worth putting one’s best foot forward from the start.