Why I like Agile - Redux

I'm in a situation, right now, where scope creep is a problem.  It's frustrating, without a doubt, but I started wondering why it was such a source of stress and made some observations.

I'm a person who likes things very ordered and I suspect that most good developers are successful at what they do because they, too, like things to be organized and ordered.  If your going to be using a waterfall type approach to manage the project, ordered means having to know, up front, what all tasks need to be completed and how long each will take.  Without this information, there's no way to know if the project is on track or not as it progresses.

Business people don't seem to work well, that way.  Typically, they'll get their hands on a nearly finished product and start finding exceptions to the rules that were first specified when the design was being made.  Bottom line, here, is that there will almost always be late-breaking requirements and modifications that will be specified.  Knowing this can get you half way to a point of being stress free.

The other half of the frustration stems from the fact that these late-breaking revelations are contrary to the method used to manage the project.  The whole process used to manage the project gets stood on its ear and the project goes into a kind of suspect status because our process is not equipped to handle this disruption of the project flow.  This causes stress on the development team and causes the project stake holders to get nervous.

If we accept as fact that requirements are going to change and that users are going to think of things they didn't realize during the requirements gathering stage of the project, and make that fact a part of the process we use to manage the project, these changes don't come as a surprise to anyone involved and the stress level drops considerably.  To the developer, the change is just another item on the back log of tasks and to the business side of the house it just means they're going to get what they REALLY need.

The key, here, is that you have to start the project out with an agile approach so that everyone's expectations are set from the get-go.  Trying to switch an existing project to an agile method somewhere in the middle is a sure recipe for crash-and-burn.