I recently attended a ScrumMaster certification course here in town and have become a certified ScrumMaster. I've been looking at implementing some type of Agile techniques for a while and finally decided to focus on Scrum.
All Agile methodologies have the same basic idea: customers don't know what the hell they want so there's no point busting your ass by creating a huge requirements doc at the beginning of the project. Contrary to Joel's ideas, Big Design Up Front (BDUF) usually guarantees that your project will fail. Most waterfall projects use BDUF and try to manage change by implementing a rigorous change request process. Agilists argue that while this can help control the chaos, it doesn't make the client happy and usually ends up forcing them into accepting a product that they don't really like.
Of course, there isn't any Agile magical wand either. Instead, Agile methodologies like Scrum simply promote the value of having the customer involved in the project rather than only involving them during the BDUF stage. By having the customer available, documentation can be minimized and developers can simply ask questions as they come up. There is certainly still a need for some discussion and design at the start of the project but it is drastically reduced.
In addition to involving the customer, Scrum is similar to other Agile processes in advocating an iterative development process. Depending on the size of the project, these iterations (or 'sprints' in Scrum jargon) can last anywhere from 1 week to 4 weeks. The goal at the end of the sprint is to have a working product that the client can use. Of course, this product will be feature limited if your schedule needs more than 1 sprint. But the goal is to let the customer use the product and change it as they see fit.
I can just see all of the developers in the crowd gasping 'They can change the project after I've started it''. The answer is Yes. That's the beauty of Agile ' the customer can manage the development process to ensure that they get what they want. The beast of Agile is that the cost can spiral out of control if the customer keeps changing their mind. Of course, that's where a handy ScrumMaster has to manage the process to ensure that everyone is making informed decisions.
My primary purpose for attending the training was to help implement it at TG. I took along 6 of my guys to ensure that we all had a similar understanding and could call 'bullshit' whenever somebody tried to cheat the process. I'm definitely attracted to the common sense project management that Scrum advocates. It will be interesting to see if common sense is accepted in a corporate environment where common sense can sometimes be a 4'letter word.