I’ve talked to a bunch of people lately who tell me they are doing iterative development. When start asking questions, it sound more like they’re doing something between iterative development (as I think of it) and waterfall: All the requirements are done up front, the development team works on some set of requirements for two weeks, and then turns over to test. The developers are still putting in long hours to meet iteration goals, and project managers are focused on tasks and dates. The product owner doesn’t see the product until the dev team is done with all the requirements (or time runs out).
I suspect they gain some benefits from doing this, since testing is spread out through the effort.
And I think they’re missing the big benefits of iterative development — managing schedule and requirements risk.
If you want to get the most out of iterative development
Prioritize requirements. Always work on the top priority requirements. The product owner gets to reprioritize at the beginning of each iteration.
Save the detail requirements definition until you’re ready to work on that chunk… things will most likely change between the time the product owner has the idea and when the team starts working. And people always learn more as they work with the ideas.
Get feedback from the product owner, customer, or customer surrogate at the end of every iteration. If the feature isn’t quite right, fix it in the next iteration.
Use information from each iteration to improve estimates. Say the development team thought they could complete a chunk of functionality estimated at 400 effort hours in 2 weeks. At the end of two weeks, they find they’ve only finished half of that chunk. Adjust the expectations for the next iteration accordingly, and don’t promise more than you were able to complete in the previous iterations. Look at what factors caused the difference and take action based on what you learn.
Use burndown charts to show progress and predict completion. Task oriented project schedules attempt to determine what will happen in the future and then attempt to force reality to meet that model. Burndown charts show how much work is left and how fast it’s getting done. Burndown charts show what is actually happening and allow decisions based on what is, not what we wish would be.
