Each Iteration is Better

That's the theory any way.  An iteration is defined as "A process of repeating a set of operations until a specific result is achieved".   Iteration in software works because we can typically build something quickly for stakeholders to review.  From that feedback, we can revise the design.   For stakeholders, sometimes they don't know exactly what they want, so iterating allows them to change their minds without waiting until the final product to discover it wasn't what they wanted at all. 

This funny picture shows all the stakeholders involved in a product and how it can go oh-so-wrong.  Iterating through the project can make this picture not so funny-sad.  Yes the customer will explain the project like the first picture and the first iteration might deliver the second picture.  "But it doesn't swing", says the customer.  OK, we'll fix it to make it swing.  There's the third picture.  But oh, I need it to go around in a circle too!  The fourth picture won't happen because the programmer was already delivering the first two pictures, right?  And the descriptions don't matter, because we are using an Agile development process where "Working Software over comprehensive documentation" is what is at value.  There wasn't a separate installation, the product was delivered in phases so the seventh picture shouldn't occur with iterations.  How software gets supported - remember, all the stakeholders should give input into iterations, including support staff.  Iterations would make this series converge on the last picture.  With each iteration, the first picture would  evolve into the last picture - and with hooks on the rope so it can be more easily replaced by support staff! 

With iterations,  each design cycle should narrow all the possibilities of change so that the project can move forward.    For iterating to work with software or really any product design, all the stakeholders must have a clear picture of the final product.  In practice, this doesn't always work.  For example, the customer has one vision,  and several iterations are completed, and then a new vision emerges.  This is often considered a positive, as iterating is a discovery process for all involved.  However, most stakeholders involved need some kind of finish criteria and often a date is involved as well as money.  If you take the customer on a journey to figure out what they want,   it should be clear that there you can't predict when this could end. 

I've been involved in several projects where convergence didn't happen.  One was a case where the product was documentation to describe an existing architecture.  I couldn't get stakeholders to agree on what the architecture was.  I iterated over it several times and was honing in on something and slowly but surely bringing stakeholders along.  But one stakeholder, who was only marginally involved decided at the last minute that the architecture description was all wrong and that I needed to take a completely different view point.  His idea wasn't wrong, it was actually an interesting take on our system,  but I was running out of time.  It was frustrating.  Since I could not get stakeholders to agree, I drew up a financial statement showing what the company had already spent on this effort and that convergence was not going to occur, and I recommended they give up the effort. 

Here's another twist on iterations.  You need a team that trusts each other and is honest, while still being respectful of course.  One the stakeholders was the president of the company.  He wrote up an architecture a few years earlier and had several people review it.  Everyone said it was good and correct.  I realized that no one had the gumption to give him the feedback they were giving me.   I guess I should feel lucky.  His architecture description was not very good.   So even though it looked like his documentation converged, it truly didn't.  It wasn't used by anyone (except him), there were things incorrect with it, and it wasn't a useful description.  

Iterations often don't converge in real projects because we run out of time and thus we are stuck with what we've got.  I observed non-convergence in iterations when I was in Copenhagen recently, and I visited several furniture design museums.  I was fascinated to see these modern furniture designers used iteration. 

But when I saw these chairs, they all looked wonderful - beautiful designs in their own.  They didn't seem like incomplete versions of something.  In part this is the nature of furniture design versus software.  You have to build a chair and then build another chair for each iteration, versus just the legs.  But in this case, it seems like the furniture designer was not heading towards an end goal. 

I have a hard time figuring out what the designer's goals were with the first row of chairs.  It seems like he started with something more traditional/colonial, made it smaller and more simple, and then made some radical changes with the last chair.  This last chair doesn't look all that comfortable, but it is simple and beautiful.  In the second row is that each iteration - something was taken out, to make the chair more simple.  Each chair in the is functional and beautiful. 

A design that meets all its goals perfectly will not always lead to the simplest design.  And yet the two most simplest chairs are arguably the most beautiful.  From my experience,  the simplest software is the most beautiful as well.

My rule for iterating is stop before you made it too perfect.  Meet a minimum set of goals which may deliver the best form.