You'll all know that Joel (
of Joel on Software fame) is a great fan of big upfront design and in a crucial point he is right. The cheapest place to fix a problem with software is when it's still a bunch of text (or a diagram) on a piece of paper.
Unfortunatly, there are circumstances where the only sensible approach to take to software development is an agile one. We have such a set of circumstances right now. The company I work for currently sell a Cobol based bakery control system. Not too surprisingly our customers are now complaining that they need a modern gui based system, not to mention the fact that maintaining a Cobol application is becoming harder and harder. So we are going to produce a .Net based, distributed application (that can either be run at the customer's site, or from our site using an
ASP model).
Now that sounds well and good, but the problem is that all our customers have a clear (and varying) idea of how the system should work. On top of that, senior members of the company (and by that I mean people who have been here since the dark ages) also have a clear idea of what the product should do. Add to this the fact that the company need to start work on this product as soon as possible, the only sensible way to tackle this is using an agile methodology.
Doing this allows us to start work before the full user requirment document is complete, as we only need the the tasks in the first iteration to be "nailed down". It also means that the customers will get an early view of the product (as the end of each iteration allows a period of customer evaluation and remediation) and their views can be fed into subsequent iterations.
So will this work? Will it be better than big upfront design? Well I think it will be, but why not stick around and find out, as I'll be posting in this category as the development unfolds?