In a place that makes software all day, the term “iteration” isn’t uncommon. When that place has been an Agile shop since the term appeared and an XP shop before that, the term “iteration” can be easily taken for granted. To us makers, iteration is a very tangible, every-day term that defines our work for each week, and sets the pace for interacting with our customers. It means that we build and deliver a set of features, check the results, then add and improve on them the next week. But how broadly is this definition known?
My fellow Atom, Paul Hart, brought this up at the snack table recently. “Most people don’t know what the word ‘iteration’ means,” he said. He was speaking to its novelty for anyone unfamiliar with Agile software or project management worlds. And he’s right. His observation made me realize that we makers owe our customers an explanation when we use the term.
OK, so it’s possible they’ve heard the term before. Two other contexts come to mind: calculus and business.
h2. Iterating in Business
p. To “iterate on an idea” is a common enough phrase to anyone who spends time in business meetings. In that context, “iterative” might be a euphemism for “incremental.” It usually means that the idea needs more time or that some opinions haven’t been heard yet. It’s business-speak for “keep trying.”
But when agilistas talk about “iterative” process, we mean something else. My favorite way to disambiguate these is via Jeff Patton’s Mona Lisa analogy. His visual demonstration shows an iterative vs. incremental approach to painting:
h4. Incrementing
h4. Iterating
“His exploration of the two terms and their importance to building software”:http://www.agileproductdesign.com/blog/dont_know_what_i_want.html is good enough to be called required reading for agile software customers or developers.
h2. Iterating in Math
The other chance our customers may have heard this term is from a calc class in high school or college. “The Newton-Raphson method”:http://en.wikipedia.org/wiki/Newton%27s_method is an example of a commonly-taught “iterative method” for finding the roots of an equation. This usage is much closer to our meaning in modern software planning, and we can see that the visualization holds truth in both contexts:
p=.
The figure shows a series of successive approximations of a curve. The analogy in software is that we are iterating in order to discover the shape of the product we are building. Nobody knows its exact form when we start, but every time we bump into it with user testing and acceptance metrics, we can describe it with greater accuracy.
In software, the iterations reveal the “correct” product, sometimes even if that definition changes over time, or even if the answer converges and diverges cyclically before we are done.
This leads me to admit that my own first experience with the word “iterate” was when I learned about “iterated function systems”:http://en.wikipedia.org/wiki/Iterated_function_system as a kid. The idea blew my young mind: you can generate incredibly complex forms by iterating over a simple set of rules. Results like this inspired me to write some of my first programs:
p=.
h2. You keep saying that word…
Before Paul’s observation, I wouldn’t think twice about using the word “iteration” in an explanation of our process. I think most people pick up the meaning intuitively as they are shown the weekly reports and progress. But the word and its roots (pun intended) can increase shared understanding of our process and the goals we seek when delivering software iteratively. The next time you use the term with a customer, take some time to explain its richer meaning.
I’ve avoided this problem with clients by not using the term. Instead I use ‘cyclical’, which is a word you don’t need to explain much and still communicates the process properly.
That’s a great idea Kevin. There’s nothing wrong with avoiding the ambiguity by finding a better term. Cyclical is certainly more accessible, though I’ve always liked the hint of positive direction in “iterate”, and the subtle implication of eventual completion. Alistair Cockburn (who has a long history of trying to disambiguate incremental and iterative) has shown that “cyclical” and “iterative” can work together as well.
Another possibility is to try to free ourselves of the term entirely by making continuously and focusing on intermediate milestones rather than temporal boundaries. Atomic’s Shawn Crowley wrote about his experience with something similar in “Managing agile, Poly-skilled Teams with Intermediate Milestones”.