Greg Polen, Dominion Inventory, DriveDominion.com

I’m not certain when agile was first used to describe software development, but over the last few years, it’s become the term of choice for so many in describing their environment and approach (though not always the actual methodology being utilized).

So what does Agile methodology really mean? Let’s start with a couple of very basic descriptions:

Waterfall is rooted in having all requirements in advance, then going off and building to these very exact specs. There’s not a lot of opportunity for change, and when alterations to specs are needed, they can be costly both in terms of time and money. Never mind the fact that they don’t tend to allow for evolving or changing needs from the perspective of the user (who by the way typically has little or no voice once the build begins). 

Agile is about getting things started and teams producing quickly. It seeks to provide a more fluid or dynamic approach, allowing for the user to be highly involved in the software development process, and thus brings a highly adaptive development environment. Change is expected, and adaptation is not overly expensive because it’s inherently accounted for. The user is always highly involved throughout the development process – because the process never ends.

There are lots of good styles of Agile out there, including my personal favorite known as Kanban (internally we used to call it hyper agile), but they all generally adhere to the basic tenets of agile development. They value changes and adjustments, feedback, and discussion – especially with users. They make room for gut checks all along the way, making sure that the product is continuing to bring value for the user. Course corrections during development are part of the plan and necessary. Extending from the first set of delivered product functionality, the agile methodology is about bit by bit refinement and improvement through constant communication with the user.

In Agile, user stories are created to replace all of the upfront requirements of Waterfall. But, when user stories come with too many detailed criteria, are too far time-removed from creation and selection, or require too many internal and management or other approvals, and [important] don’t involve the user in the overall process, aren’t we really just describing Waterfall with some window dressing? In this style, teams tend to spend much of their time on predicting project durations and feature sets and writing specifications and technical documents instead of interacting with users. Despite the application of select agile features such time-boxed development iterations, or Scrum style management, this isn’t a particularly agile approach. It tends to run counter to true agile philosophy.