Face Change With Agile Methods
Change is inevitable in development. Agile methods will help you deal with it.
by Brian Noyes

Agile methods have been getting a lot of press lately. The term agile arose from the problem with categorizing methodologies in a binary fashion as either lightweight or heavyweight. The fact is that most methodologies emphasize certain goals, practices, or principles at the expense of others, and thus can be called lightweight in some areas and heavyweight in others. Few of them try to be lightweight or heavyweight—they simply try to be fast, thorough, and effective.

Also, both "lightweight" and "heavyweight" carry negative connotations that most methodologists don't want to be branded with. So in early 2001, a group of well-respected names in software process methodologies got together and tried to capture what they were all striving for. They came up with the Agile Manifesto (see Resources), along with a list of the signatories. Out of that, many software processes that were trying to attain some of the same goals and philosophies captured there have started grouping themselves under the banner of agile methods. I'll give you a quick overview of the term "agile methods" and some pointers for more research (see the sidebar, "Core Concepts of Agile Methods").

The underlying theme behind agile methods is the acceptance and facilitation of change. One invariant in any software development project is that there will be change—change in requirements, change in talent and personnel, change in knowledge, change in technology. Another key focus in agile methods is to adapt rather than predict.

In traditional software processes, the approach was to prepare for change by trying to anticipate it all and predict what might change ahead of time. This involved performing extensive requirements analyses, capturing them all in comprehensive documentation, and reviewing them with customers and developers until everyone knew exactly what needed to be built before the work ever started.

Implementation is Easy, Right?
Then came the design phase, which tried not only to account for the specific captured requirements, but also to provide hooks and flexibility so future changes could be anticipated with a preemptive strike at the outset. Finally, the programming work would begin, and the design implementation should simply involve turning the crank like a manufacturing assembly line, right?