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.
