The agile manifesto is the foundation of agile software development. Various branded versions (Scrum, XP) promote “iterations”. Iterations are these methods’ approach to facilitating agile’s value:
responding to change over following a plan
and by extension to the second agile principle:
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Are iterations the only way to respond to change? No. Kanban, for instance, adapts more frequently. One could reasonably argue that that Kanban should be termed “continuous adaptation to change”.
Remember when weekly builds were all the rage? Then it became daily (Harken back to The Joel Test, circa 2000. Daily builds were in it). Finally, we got to continuous. Now we’re bridging the last mile in a continuous fashion, through continuous delivery and continuous deployment.
Iterations are today’s backlog management equivalent of weekly builds – a step in the right direction, no doubt, but not the final answer.
I’m tired of folks who argue that you’re not agile if you don’t have an iterations’ worth of estimated/analyzed stories prior to the iteration planning meeting. They’re missing the point. Having a fully analyzed and estimated backlog may be comforting to some, but in a frequently changing environment much of the effort to get there is waste. Even having enough of your backlog “fully” analyzed and estimated to peel off into the next iteration doesn’t mean you’re “agile”.
Iterations are like methadone for the waterfall heroin addict. Just as methadone helps heroin addicts come down from their illusory cloud of nirvana, so too does an iterative approach help waterfall addicts come down a bit from their illusion of predictability and control of software development. Just as methadone, however, iterations should be a stepping-stone; not an end-state.