While agile methodologies enable natural team collaboration, the way we people naturally work as a team, the apparent freedom must not be misused.
In the beginning of 1990’s, I was lucky to be able attend a C++ course in Copenhagen, held by the master himself, Bjarne Stroustrup. It was not an everyday introduction to a programming language, but an in depth two day coverage of everything you would want to know about C++. And as Stroustrup himself put it, he was not in the business of giving C++ courses, so it was also the opportunity of a lifetime.
The two day period in Copenhagen was memorable, but there was one thing that I remember over everything. That was what Stroustrup said about software development: No software is ever designed, it just evolves.
At that time, waterfall methods of software development where widely used. I was just learning Structured Analysis and Stroustrup’s remark sounded like heresy to me. But it was very tempting and actually it was very true.
Today, agile methodologies are the name of the game. While the concepts of agile development are several decades old, they have become mainstream only during past 10 years.
Agile methods inherently include an assertion, that many software requirements cannot be strictly specified at the beginning of the project. This is especially true with large and complex projects.
But an agile method, as any other process, can be a weakness if you forget what the true purpose of using a method actually is. The purpose is to provide, at the end of the project, a functional system, that is a useful part of the real world. Something that your customer needs and wants to use.
So take care to be agile enough to allow you software to evolve. But also be sure to check, that the selection pressure always comes from the right direction: your customer.