So far I have been talking about aspects of agile methodologies that I am not a fan of. So lets look at what I am a fan of. One aspect of Agile Methods that I am a big fan of is the definition of done. Done is a sore spot in project management. People tend to define down based on what they have to do personally. For a developer, done typically means that the code is complete. The trick is that the no one cares if the code is done, except the developer. The customer is not buying code. The customer wants to know if they can use function XYZ. Project Management for development projects looks for the completion of functionality XYZ, but typical development projects are not organized or focused on completing XYZ. The more common organization is that the Developers work on their own, the QA people work on their own, the Doc Writers work on their own, etc. Of course they interact, but they do not work together. This leads to a "my part is done" mindset. If I am a Developer in a group of Developers, what can I say about a feature except that the code is complete?
The Agile approach is not to group Developers, but to put a couple of Developers together with a few QA people and a Doc Writer. Now I have a team (hopefully), that is focused on accomplishing some chunk of functionality. Obviously putting people together in a room does not make them a team. Still you have a group that has the possibility and perspective to be focused on completing some functionality for the Customer. What is even better is if the Customer is part of that team as well. Then you can be very confident that the functionality is not only complete, but actually what the customer wants. It wont be all of what the customer wants, but it will be something.
This is a huge change from the way people in this industry typically work. Its a change no one will really want. Still, it can have a dramatic effect on what you get down, and how happy your customer is.
Knowledge is like an Island
10 years ago