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.
Coincidentally, I attended another seminar some 5 years ago where another scandinavian IT guru, Ivar Jacobson, gave a presentation. Jacobson is one of the original creators of Rational Unified Process (RUP), and curiously his pitch was about how he had discovered that RUP was not right answer to SW development in the end, and accordingly he had initiated SEMAT to shape a more practical methodology for SW development.
It seems that we’re still in seek for the perfect methodology, and that also gurus can and need to reform their opinions occasionally.