June 12, 2006
A recent conversation made me realize how easily a mismanaged iterative development cycle can become a waterfall.
Break work out in stages, fine. Use those stages as short iterations with scheduled releases, building toward a final release of a "finished" product, good. Build on what you learn during those iterations to progressively refine your understanding of the requirements and your design, good.
Uncover important requirements and/or significant design flaws in early stages, but explicitly label these findings as "new features" that won't be implemented because you didn't know about them during the Big Design Up Front and now you don't have time… not good. You've just missed the point and lost the advantage of iterative development.
It's not enough just to know that requirements will change during development: you should act accordingly and build your process around the expectation of change. When requirements change (and they will), but you respond as if they have not and must not, then your process is broken.
