Agile or Traditional?

I was recently speaking with a friend I haven't seen in months and she mentioned that she was reading a book I had lent to her. The book is called "Balancing Agility and Discipline" by B. Boehm and R. Turner. The book's main theme is the attempt to balance agile software development methods with traditional methods. The idea is to try and assess your project by looking at several different characteristics and then choose the processes from each method that will allow you to best manage it.

So that idea got me thinking about my most recent project, a Java rewrite of an existing application, and how desperately we were trying to use a pure agile methodology when it didn't really fit.

Here's a quote from a presentation available on the "American Institute of Aeronautics and Astronautics" website:

Problems characterized by change, speed, and turbulence are best solved by agility.

• Accelerated time schedule combined with significant risk and uncertainty that generate constant change during the project.

Is your project more like drilling for oil or like managing a production line?

• Oil exploration projects need Agile processes.
• Production-line projects are often well-served by rigorous methodologies.

Our project was undoubtedly a production-line application with very low risk:

• Although I didn't really like the technology we used on this project, it was being used to some degree of success on two other projects. So while it was undoubtedly not very productive, it was usable.
• The database design and user interface design were to be lifted untouched from the existing application.
• We were mandated with reproducing an existing production application so the requirements were well known if not well documented.
• Business users were not co-located and not easily reached for consultation (during the entire project I never spoke to a single person who would actually use it).

So what drove us to try and use an agile methodology? Well.... it's trendy. Agile is "in" and waterfall is "out". IT people would like to live in a world of absolutes, where we can say with certainty that A is better than B. But the reality is that we live in a world of spectrums where things are classified in terms of a position on a scale between two extreme or opposite points. Just like we shouldn't try to develop a simple project using every conceivable J2EE technology and framework available, maybe we shouldn't try to apply every agile process available where it just doesn't fit. Sometimes it's okay to create a plan and to write down requirements. Sometimes it's the best thing to do.