Agile development - can’t scale, won’t scale?

Where’s the point of no return?

Reg Reader Workshop Who could fault the base principles of agility? I was recently talking to a CIO of a European telco, who was totally bought into the strategy of delivering services as fast as possible to customers. In this fickle, subscriber-based market time literally means money won or lost relative to the competition.

“Agility is a business strategy for us,” he said, explaining how IT services needed to be driven by fast-moving business demands. In practice, boiling down to deliveries of new software releases every few weeks. “You don’t know what your business will look like in two years, so you need to organise your development practices accordingly.”

But – and it’s a big but – just how practical is this in reality? One of the dangers of talking to someone who has already “got” what there is to get around agility is that they make it sound more simple than it actually is. It's like asking John Williams (or Joe Satriani, whichever is your preference) to explain about playing the guitar. Things can be a lot more challenging for many organisations considering more agile approaches to software development, whether they're adopting a particular methodology or just some of the principles.

In particular, we have the question of scale. When striving towards some absolute goal, getting there can become harder and harder as things go on, to a point where it becomes impossible. So it is with software: I’m in no doubt that a very small company can adopt agile principles and practices with relative ease. Indeed specialist agile consultancies paint a pretty good picture that they know what they are doing.

But what happens when there are more than 30 people on the project? Is it still possible to be agile when there are 50, 100 or 500 developers, analysts and managers involved? Is there a cut-off point where agile principles and methods start to become more trouble than they are worth? I’m really not sure – as in, I genuinely don’t know. Can it be done? What needs to be done? Where are the challenges? Are they around quality management, collaboration, testing, integration - or where are they? We’d love to get your feedback, so let us know what you think and we’ll feed it into the research machine. ®

Sponsored: Designing and building an open ITOA architecture