What Does “Iterate” Mean?

In a recent post I explored whether Agile is muddying the waters, confusing organizations and making it more difficult to pursue smarter ways of working. It was a rant, of course, but was one that really seemed to resonate with people. One of the things called out is that no one can even seem to agree on what “Agile” means anyway. Beyond citing the manifesto, one of the most frequent definitions is that Agile is an “iterative” approach to work.

But what does that mean?

Designers, for instance, seem to understand iteration differently than many agilists do. About five years ago, back before Twitter was the dumpster fire that is now X, I was making some comments about this which caught the attention of none other than Ron Jeffries, one of the coauthors of the Agile Manifesto. In true Ron style, he set me straight.

Glad that’s cleared up. So, all is well and good…or is it? What about industry experts such as Jeff Patton or Alan Cooper? 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?

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 iterating. Agile consultant John Miller then posted an image from an article by Alistair Cockburn, another coauthor of the Agile Manifesto. In it, Alistair interestingly says that “incremental” means building parts of a system at different times or rates and “iterative” means revising or improving things already built. Alistair then joined the thread as well:

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 an illusion of alignment and 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.

Following these exchanges, I then saw that Martin Fowler, another Agile Manifesto coauthor, has yet another definition of iterate! For Fowler, 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 their 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 Erika Hall).

Until next time.

If you’re interested in coaching, contact me.

You can also visit my website for more information.