Iterate, Don’t Increment
The Old Way
Fifteen years ago, the prevailing wisdom about how to deliver software in large enterprises was some variation of:
- Define all the requirements
- Build all the functionality
- Profit
That mindset, however, led to all kinds of problems including missed deadlines, canceled projects, and—occasionally—working software that nobody wanted to use.
The New (Old) Way
Today, in the age of Agile development, we know better. We gather User Stories in a Product Backlog and measure a team’s Velocity as they burn down that backlog.
In other words:
- Define all the requirements
- Build all the functionality
- Profit
Derp.
Incremental ≠ Iterative
It seems that, despite what some manifesto might say, we still really, really like following a plan. Responding to change? Not so much.
From my perspective, this boils down the distinction between incremental and iterative development.
Breaking down a big plan into lots of small steps is easy: It’s the same plan, just executed in smaller increments! Continuously evolving your plan in response to feedback is iterative, and that is much more difficult for large organizations to grok.