A few years north of a decade ago, the terms "iterative and incremental" were how folks increasingly spoke about software development.
Somewhere during the the past handful of years, coincident with the mainstreaming of agile, we lost track of the “incremental” part of “iterative and incremental”, and began to talk almost exclusively about software development as “iterative”.
“Iterative” has become practically an omnibus term, and somewhat meaningless in many of the contexts we use it in. We use “iterative” in contexts where “incremental” is likely more appropriate, as in, “That feature will be available in the next iteration of the product,” rather than, “That feature will be available of the next increment of the product.”
Further complicating things, we commingle the notion of fixed timeboxes with "iterative". We try to start and finish work items coincident with these "iterations". We do planning in iteration-sized chunks. And we schedule meetings and deliveries so that they too are coincident with "iterations".
I started to shift to Lean software development earlier this year, and started questioning (and later abandoning) Agile’s typical fixed timeboxes, and replacing them with continuous flow.
As I move away from timeboxes and the fixed timebox that we refer to in agile as iteration, I find myself thinking and scheduling in increments. Not only does this gel more with the reality of what’s really going on in the team and the project, but it also gels with the whole message of “iterative and incremental”.
Iterative development is how we build increments of our product, but it's not really the defacto scheduling or product design unit that we’ve come to use it as. Iterative is a quality the describes and governs each move we make in almost every aspect of turning ideas into products. It’s a workstyle rather than a yard stick.
In losing track of the “incremental” – even if in nomenclature alone - we’ve gradually become uncentered. And in filling our senses almost exclusively with the “iterative”, we’ve taken the iterative to the extreme and tried apply it to facets of software development that are more appropriately served by the other half of the equation. And not surprisingly, we’ve suffered the repercussions of imbalance and excess.
With a more balanced perspective of “iterative and incremental” we have the opportunity to step back and more easily see that there are alternatives to fixed timeboxes that are perhaps more natural and maybe even more effective. And we have the opportunity to see that scheduling is just scheduling, resource planning is just resource planning, deliveries don’t always have to happen every Friday, customer demos don’t make sense until features are meaningful to customers, and iterations aren’t fixed timeboxes unless we say they are.
And none of this in any way refutes what we’ve learned about the benefits of smaller batches.
And maybe without "iterations" we'll get an a bit better understanding of how trying to have a single heart rate without leveling flow is like trying to have a single heart rate whether you're running up a hill or napping in your hammock. And maybe we can start to turn our focus to flow as the enabler and see the heart rate as the natural side effect of just being at work while being alive.
