The following bullet list sums up the GOALS of agility:
- If your requirements change you bend (and you do it in a robust and timely manner), but you don't crack
- You are able to constanlty improve desing and architecture without major delays
- Give the customer what they need at the end of the development process, not what they asked for at the beginning (unless it's the same thing)
- Do not burn people out while accomplishing previous goals
If you'd like to know HOW you'll be able to achieve all of this you might wanna have a deeper look at AGILE methodologies, bad news is there's around 1000 of them out there; they're basically fishing from the same AGILE pool of which they share the core. Talking about the core, it's easy to give a list of popular practices that can help to achieve the goals above, but how to use'em and which you should use and which not is up to which methodology you choose to adopt (you don't need to pick one, you can always create your own picking and mixing from the pool of AGILE practices, everyone seems to be doing that); just to name a few, XP is probably the trendiest, but the ICONIX process methodology is gaining lots of worshippers around, so keep an eye on it.
Anyway, here a list of popular AGILE practices, just to give an idea (random order):
- Test stuff like crazy - Test Driven Development (TDD) paradigm lives on this
- Involve your customer as much as possible
- Release like crazy
- Integrate your code like crazy
- Collective Responsibility (everyone knows about everything - in theory)
- Pair Programming (and pray your buddy is not an asshole)
- Optimize team communication (put buddies near to each other)
- Keep iterations short
Hopefully now it's clearer wtf AGILE means, but I wouldn't be surprised if not. Truth is AGILE doesn't exist.