Iteration, Increments, and Timeboxes
Like many words, we often use “iterative” and “incremental” quite loosely. I’m OK with that, until that lack of precision causes misunderstandings, disagreements, or misdirection of effort.
It’s quite common for Agile teams to speak of an iteration as a synonym for the Scrum term sprint. Both of these usages really mean timebox.
A timebox is a fixed amount of time given to accomplish some goal. Using a timebox guards against the risk that the work toward that goal will grow unchecked, perhaps without achieving the goal at all. We might reach the end of the timebox without achieving the goal, in which case it would be prudent to reassess the situation. Perhaps we should try a different tactic to reach our goal? Perhaps the goal is not valuable enough for us to spend more effort?
Sometimes the approaching end of a timebox helps us a focus on getting something done, rather than doing the best and most perfect thing. The approaching deadline may stimulate choosing the current best choice identified and avoid the analysis paralysis that leads us to continue looking for better possibilities. This effect is often called the student syndrome and described with the observation that, “if it wasn’t for the last moment, nothing would ever get done.”
When we line up equal-sized timeboxes end-to-end, we gain further advantages in planning and observing progress. We can simply compare the results of one timebox with another, without any fiddly mathematical calculations. We can presume that, all things being equal, future timeboxes will be about as productive as past ones, making estimates into the future reasonably accurate without undue precision.
Human beings seem to do best for the long term when they get into a rhythm in their work. Work songs and sea chanteys were ways to synchronize the rhythm of manual labor. We can get similar benefit using timeboxes for software development or other complex knowledge work.
Where do iterative and incremental fit into this?
Incremental development means that we’re building the end result bit by bit. We can look at this from many angles. Each timebox of work produces one increment. Or each feature we build can be seen as one increment. Or each module.
Project managers have used incremental development for a long time, sometimes effectively and sometimes not. Working in timeboxes is one thing that helps incremental development work better. Another aid to effective incremental development is delineate the work as functional pieces, rather than arbitrary modules. This helps us to know whether an increment is really done or not. And we get a better sense of rhythm if we make these functional increments small and frequent.
But what if the functionality is too big to fit into the timebox? That’s why (well, one of the reasons) we also want to iterate.
Iterative development means going over the same thing repeatedly. Think of smoothing a board with sandpaper. First we sand with coarse grit to knock of the high spots quickly. Then we come back over the same board with medium grit to level the surface more precisely, removing the scratches left from the coarse grit. Finally we switch to a fine grit, removing the smaller scratches of the medium grit without removing large amounts of wood and leaving a more polished surface.
Working in an iterative fashion helps us move toward our goal in smaller steps. It lets us interleave working on the various functions we want to incorporate, effectively doing all of the coarse sanding before proceeding to medium grit on any of them.
And when we look at the product/project as a whole, each timebox is one iteration of the whole. Hence the popular usage of “iteration” to mean “timebox.”