It's plain for all to see that Agile is the "next big thing" in software development. Products long since established have been given the Agile makeover, a host of consultants with years of experience have appeared on the scene, and a thousand books and articles, extolling its virtues vie for our attention. Truly the headlong dash to Agile - and to set cash registers ringing - is on.  So how much is really new, how much is hype and what's likely to stand the test of time? 

In truth, just like the rock band that toured for years before achieving "overnight stardom", many of the key principles of Agile have been around for years. Words like iterative, incremental and spiral, to describe alternatives to waterfall, have been used at least as far back as the mid-eighties and most probably longer. RAD in a number of guises, most note-ably DSDM, has been around since 1991, Scrum, a leading Agile approach, since 1996. 

These approaches have a common set of principles and techniques that are at the heart of the Agile movement:

*    Full time user involvement

*    Short iterative and incremental development cycles

*    Upfront prioritisation of requirements along MoSCoW principles

*    Time-boxing

*    Multi-disciplined development teams

*    Prototyping and an evolutionary / learning approach to development

*    Burn down charts

*    Rapid build and integration cycles    

*    Application of the 80/20 rule

*    And so on and so forth ...

So what's really new? Well people will argue about this until the cows come home but from my own experience of working on a DSDM project ten years ago and an Agile project today, here's the list: 

*    Daily stand ups

*    Test driven development

*    Explicit recognition of the importance of re-factoring

*    A whole host of new development tools to support the approach

*    A much more dynamic planning process  

Do the handful of points above really justify all the hype? Well in truth it's perhaps unfair to say that this is the sum total of the Agile movements efforts. As a software development professional I can see four hugely important changes that the movement is helping to bring about:    

First and foremost it has pushed the software practices listed above right back onto the agenda of IS decision makers at a time when they are struggling to make a success of the "last big thing", offshore development 

Second, it has taken the practices, optimised them, and helped spawn a whole set of tools - Junit, Clover, Checkstyle, Findbugs, etc. - to support them. Whilst good in itself, the real benefit is that it allows code to be changed - refactored - with high confidence that it will still work and this in turn allows the design to mature as the understanding of the problem domain improves. In other words we now have real iterative design and development.

Third, it promotes the idea that software development is analogous to the process of product development rather than the processes of production. This is a major shift which recognises the software development is at heart a complex, problem solving process, that for all but the simplest projects mandates an evolutionary approach.  

Last but not least it firmly places people, rather than processes, at the heart of the development effort. Good software engineers should be recognised and valued as craftsman, rather than shop floor workers.       

Though it pains me to see all that money spent on books, consultants, training courses and all the rest, due to the four reasons above, I have to support it, not because the gurus and books have convinced me it's a good thing - I've been caught that way before - but because at last the industry seems to have caught up with the methods and approaches that common sense people like you and I have been working towards for years.  

So should we throw away all other methods and adopt Agile in all its glory to all new project no matter what their size and complexity? Forget RUP, UML, Use Cases, Robustness Analysis, Product Based Planning? Well perhaps that's not too wise.  I like RUP, especially the objectives of its four main phases. I like the idea of identifying; describing and agreeing the major products the project has to deliver upfront, so that the team has clear objectives and measures of success. I like the granularity of a system Use Case, designing the system around the users goals is difficult to argue against. Creating an initial static class model and doing a few collaboration diagrams on a whiteboard to establish an initial software architecture before going to code simply feels like common sense.    

So my prediction and hope for the future is that rather than throwing the baby out with the bath water, good software professionals will take the best bits of Agile, and stick them into their software development toolbox, whilst not forgetting that at the end of the day, there really is no substitute for good people.