I recently misquoted Ron Jeffries as saying that iterating just means you’re repeating increments. He corrected me. Agile consultant Rob England also (rightly) took issue with what I’d said.
So did, for that matter, Agile consultant Neil Killick, pointing out that it’s the inspecting and adapting you should be repeating (iterating), not the increment. The increment is the work produced. In my defense I was commenting how designers often seem to have a different definition of iterate than agilists. We daily throw these words around (like value) without actually defining them. It leads to confusion.
What Ron Jeffries, coauthor of the Agile Manifesto, had actually said was that to iterate is to repeat, so all iterate really means is to repeat a process cycle. He reminded me of this, in true Ron style.
Glad that’s cleared up. So, all is well and good…or is it?
What about industry experts such as Alan Cooper or Jeff Patton? They’ve long said things like, “If you only build it once, you didn’t iterate anything,” or, “Teams don’t tend to throw code away, which means they aren’t actually iterating.” Such statements don’t really gel with Ron’s definition, do they?
So I asked Alan Cooper about his statements that teams don’t tend to iterate. He threw in his two cents:
And:
Seems to validate the point I was trying to make about there being two interpretations of the word. Agile consultant John Miller then posted an image from an article by Alistair Cockburn (2008), another coauthor of the Agile Manifesto. In it, Alistair interestingly says he first encountered the difference between incremental and iterative at IBM — a full decade before the Manifesto.
Well, according to Alistair, incremental means building parts of a system at different times or rates. Iterative means revising or improving things already built. In short, he says, incremental means add onto and iterative means re-do.
Then Alistair weighed in as well. For example:
Alistair’s use here is more what I thought iterate meant. Notice, however, this doesn’t jibe with Ron Jeffries. So, we’ve got two Agile Manifesto coauthors giving a different definition of a basic Agile term. I wasn’t the only one who noticed this.
It’s not a big deal. The same thing happens in UX. Experts often don’t agree on definitions. This stresses the importance of unpacking, of pausing and clarifying what people mean.
It can surprise us to learn that we often mean entirely different things by many of the words we throw around daily, words like customer, value, outcome, or iterate. If we just assume we know what others mean, if we project our understanding onto them, it can result in expensive misunderstandings.
Take the argument that most teams are incremental but not iterative. Notice this can only be made using Alistair’s definition. If someone using Ron’s definition argued this was false, that’s not a real disagreement — it’s a misinterpretation.
With Ron’s definition, where iterate means you repeat a cycle and add an increment, all teams are both incremental and iterative whether they revisit the work already done or not. In other words, they’re both by definition.
I then saw that Martin Fowler, another coauthor of the Manifesto, has yet another definition of iterate! For Fowler (2019), to iterate is to complete all activities for a feature before moving to another.
Agile consultant John Miller offered a sort of middle ground by arguing that to iterate just means to repeat, so the real question is, “What exactly are you repeating?” Ron, sticking with his definition that you’re repeating a process cycle, agreed that design iteration is different. When a designer repeats a cycle of her design process, he said, she goes “back to the drawing board.” One might say then that there is a basic difference between design iteration and Agile iteration — and that makes sense.
Since design starts upstream of Agile (or at least should!) and is focused on bigger questions (Agile is specifically about building software), it therefore focuses on more types of learning. Thus, design is more strategic; Agile is more tactical. It makes perfect sense that a design iteration would be a broader concept than Agile’s.
Perhaps, fundamentally, they are really just different-sized learning loops (image adapted from Hall, 2019).
References
Cockburn, A. (2008). Using both incremental and iterative development. Cross Talk — The Journal of Defense Software Engineering, 21(2), 27–30.
Fowler, M. (2019). WaterfallProcess. martinFowler. Retrieved on December 13, 2019 from: https://martinfowler.com/bliki/WaterfallProcess.html.
Hall, E. (2019). Yes! You do have time to research. Medium. Retrieved on October 24, 2019 from: https://medium.com/mule-design/the-horizon-of-inquiry-417acdbbda39.
Charles Lambdin 
2 thoughts on “Words Matter: Unpacking “Iterate””