First, let’s be clear – Agile is a software development methodology, it’s not a ‘save the world/software delivery panacea’, and in a lot of ways it’s really a collective re-badging of stuff that’s been around for ages.
The Good Guys will recognise a lot of this before, but others will cling to it thinking it will somehow magically make software development faster, better, cheaper, etc. There are plenty of books on the subject and most will tell you it DOESN’T solve everything, it’s NOT necessarily faster, or cheaper, and there are certain projects or situations you should NOT use it.
Agile brings with it lots of new exciting terminology and lots of new fabby techniques, or does it? Let’s compare Agile with DSDM and XP, or, if you’re old enough, RAD or JAD (whatever happened to that), and let’s compare it’s new fancy buzzwords with, well, errr, plain English really.
- Stories: A narrative describing something to be delivered. The old skool will recognise these as ‘Requirements’ (Epics = High level requirements).
- Sprint: A defined period of time where everyone works hard with the objective of delivering something. XP calls them Iterations, DSDM called them Timeboxes in the olden days
- Scrum: When the team all gets together to discuss what to do. Sound familiar? Yes, a ‘Meeting’
- Standup: No, not a comedian, but by now, you are may be beginning to wonder. This is where the team all gets together quickly to discuss what to do, without sitting down. You will undoubtedly recognise this in the real world as a ‘Short Meeting’
- Refactoring: Restructuring or changing existing code to make it work differently. Yeah right, you may be more familiar with the terms ‘Fixing’ or ‘Debugging’
We could go down to the level of discussing ‘dunces hats’, and ‘visible build indicators’, but you’re probably getting enough of an idea already. It’s all been done before and those in the know have been doing it for years without the daft names. Suffice to say, if you’ve mobilised a teamlet, who’ve assigned a story-captain and they’re now swarming on a work item to burn down a story, you’re already too far gone.
The bottom line is that Agile is like any other methodology du-jour; it’s right for some things and not for others, it has useful bits and irrelevant/pointless bits and it has people who know about it and understand it and people who think they know about it but don’t.
Watch out for the latter; the methodology evangelists. These are the people who will say things like, ‘That’s not the Agile way’, ‘We should have a stand-up to resolve this’, ‘we must use xyz software to track with’ (it’ll be a beta release of a freeware hack that only runs on an obscure version of Linux, or a Commodore 64 and requires you to be a seventh level mage to sign in), and generally strut about looking like they know it all.
Agile works best if you can isolate everything from the real world; the project team, their development kit, the users, the testers, the delivered system, all common sense. Strangely, us real world guys know it’s just not as simple as that…
Anyhoo, like all methodologies, it’s only partly about the methodology, it mainly comes down to the people executing them; if you have enought good people, they will stand a good chance of delivering. However, if you don’t, then the combination of that coupled with the use of a methodology new to those people , no matter how new and sexy it is, or wacky it sounds, will likely result in chaos.