I often discuss the benefits of iterative development with collegues and students.
A key benefit (THE key benefit for me) is that you can incorporate your lessons learned from one iteration right into your next iteration, thus continuously improving your process . That is, if you truly plan your evaluation and kick-off sessions at the beginning and the end of your iteration.
If evaluation leads to the discovery that in your project, you spend lots of time on bugfixing due to inadequate requirements documents, you might want to change your requirements process (and suggestions for making it better may come right out of the evaluation) and use your better process (and spend less time bugfixing) in the next iterations. When you evaluate the use of the improved process next iteration, you get the full feedback effects into your project: project members actually see that problems are tackled, solutions are discussed and improvement is measured.
I thought about this when I read a post from Roger Cauvin. Cauvin disagreed with Scott Sehlhorst who stated:
There is nothing that prevents a waterfall project from reviewing
estimates throughout the course of the project.
Cauvin replied:
With waterfall, you certainly can review and adjust estimates halfway through
the process, but you will not be able to incorporate the full feedback
effects.
I agree with Cauvin on this one. If you discover during the evaluation that the estimates given by your team are bad, you can evaluate why that is so, and change the estimation process immediately. Team members can thus improve their estimation skills in the course of the project, whereas in a waterfall process, the can improve their estimation skills in the next project!
