Size doesn't matter if you're agile...

I'm a published software guru you know. The January 2007 issue of IEEE Software contained an article written by yours truly, thanks to an invitation from guest editor Dr. Ita Richardson. She saw me present at agile conferences in Ireland and thought I was absolutely the right guy to start a fight. So that's what the article is: a point - counterpoint argument, where I taunt a genuine software guru Wolfgang Strigel and he knocks my lights out. Thankfully it's behind the IEEE Software paywall so my ignominious defeat is well hidden.

The point I was arguing - and I'm still right, Wolfgang - was that agile methodologies can be used on both big and small projects, in small companies and in large enterprises. Size should not be a factor in accepting or rejecting agile methods because even the biggest software development project must be broken down into smaller coherent chunks, and developing these in self-organizing teams is almost always the way to go.

But that's too polite. I'm going to remove my gloves and take a bigger swing, like I should have done in that article.

Most very large software projects are disastrous failures: they cost too much, they're late and they don't achieve their goals. This presentation by Roger Sessions explores the relationship between project size and project failure - this slide is an extract.

(Yes, I know the Standish metrics are contentious these days - but even if they're only half-right the conclusion would be the same.)

The traditional methods of managing large projects, all those document-centric processes, don't work very well. My advice: if you're unable to break down a project into agile-sized chunks then either do the company a favour and call a halt to it or run very far away as fast as your skinny little software developer legs can carry you.

Sometimes, Agile is a bad fit for a project but it's not because of size. I can think of two characteristics that would mitigate against agile:

• A very detailed specification has been contracted with the customer. I don't just mean a description of the features, but a specification that leaves no room to manoeuvre, which is fairly rare, thankfully. (Though see below!)
  
• The development organization is completely distributed with few co-located developers. How to  manage virtual self-organizing teams is a problem I haven't been able to crack yet, but the co-ordination mechanisms in agile such as stand-up meets, story-boards and solution white-boarding aren't adapted for this

I encountered the first characteristic in Cúram software when we were contracted to deliver a system to the UK Department of Work and Pensions. A large part of the requirements were described in laws passed by parliament. The only way to understand these requirements was for some unfortunate analyst to swallow all the legislation and regurgitate it for developers to eat (sorry), highlighting overlaps, commonality and inconsistencies. I couldn't find a way of doing this in an agile fashion; we ended up with a project structure that was quite waterfall where a team of analysts provided the requirements to rules developers, and test scenarios to testers. We delivered the system according to the contract and were well paid - but it has never been put in to service. Coincidence?

(So, you may ask, why didn't I run away from this project like I recommend above? Well dear reader, if I knew then what I know now I would have done things differently. Hence this blog.)

When I'm starting a new project I'll always try to apply an agile development approach, breaking it down into smaller chunks. I avoid projects with either of those nasty characteristics.