Conflating Increment and Iterate? Use Common Sense!

I’m an advocate of UX + Agile but it has led to some “can’t-see-the-work-for-the-methodology” blindness. People are wrapped-up in doggedly following the mechanics of the methodology and lose sight of essential common sense about how best to get the work done that initially inspired the creation of the methodology. This not very thoughtful behavior tends to dumb-down the value of the methodology, diminishing the promised gains in project efficiency… bad for any company.

You can recognize that people have stopped using their common sense when they start using the terms “iterate” and “increment” interchangeably. Mostly you will hear “iterate” used to mean either term and most often, they mean “increment.” As a result, “iterate” as a concept is obscured and all work becomes “increments,” even though people are calling them “iterations.” This can be very confusing and very bad for UX because iteration is fundamental to good UX outcomes.

Let me restore some of your common sense. Incrementing and iterating are a fundamental part of almost any human activity; they are a natural way to chunk tasks. 

Incrementing is linear-shaped or step-wise. You can divide a task into increments and often the order in which the steps need to be completed is significant. A jigsaw puzzle being pieced together is a good visual image of an incremental process, where each puzzle piece is one increment of a whole. 

Iteration is spiral-shaped and is about refinement. Iterating leads to a higher quality outcome. Classical painting, which progressively adds more color and detail all over the canvas, is a good example of an iterative process. 

“Can iteration get us incrementally closer to a better design?” “Let’s iterate on the increments until they are good enough.” Here is where the conflation of these terms begins to occur, because they are inextricably connected and do live within each other in almost any work process. 

Imagine the work of washing your car. You could wash the entire car and then evaluate your result and rewash (iterate on) any parts that are not clean enough. Alternatively, you could divide the car washing into sections – the front, the left side, the back, the right side, the top – and wash each section sequentially (by increments). Is every part clean enough? Maybe we had to make a second pass on the front of the car to get it as clean as the other parts. Now we are iterating within a framework of increments. 

Imagine cooking a meal of stir-fry tofu and vegetables with quinoa. First, you get the tofu on some paper towels to drain the water out of it. Second, you get the quinoa cooking. Third, you clean the vegetables and begin to stir-fry them in a pan. Once they are mostly cooked, you add the tofu and the seasoning or sauce. So far, you have done everything as an incremental step. Then you taste it. If it is not palatable enough, you add more seasonings or sauce to refine the taste. Now you are iterating. 

You can see in the car-wash example that breaking a task into increments is about what is a reasonable amount of work to be done in a chunk. It’s quickly obvious what a reasonable chunk of work is for an increment of a car being washed. It’s silly to divide a car into sections to wash it; it’s a small enough job to not need multiple steps. You can see in the stir-fry example that time-sensitive incrementing (constraints and dependencies) is necessary. 

On a large software development project, more is required than just off-the-cuff intuition about work breakdown. Methodologies such as Agile and Lean or even Waterfall are necessary results of scale. However, if you have an inherent awareness of how you will get specific work done, you will have a better ability to use any methodology effectively. Common sense should always rule.