On the AYE conference wiki, Jerry Weinberg said this: “no iteration should be so big that you can’t afford to throw it away if it doesn’t come out right in the end.”
The longer the iteration, the less likely you can recover the project (or re-steer it, or re-guide it to an appropriate direction). I’ve worked on several 6-9month projects where none of the code was integrated until the month before the end. At that time, even though the developers realized the code doesn’t hang together, or the product doesn’t fulfill the customer needs, the project team felt they were “so close, we may as well finish it,” even though it’s not going to meet the company’s needs.
If we did shorter-iteration projects, we’d be more likely to cancel (early!) the projects that have no hope of succeeding.
Aside from the difficulties of completing projects, we’d be more likely to successfully complete projects with short iterations. Short iterations have these benefits:
- You know if you’re making progress
- You know who’s not making progress
- Your users or user-surrogates have an opportunity to ask for changes early, rather than later
- Short iterations are fun. Everyone gets to make progress and cross things off their list
So make your iterations small. One week is probably too small. Six weeks is probably too long. Think about how much work you’re willing to throw out if it’s wrong, and that’s the right size of your iteration.