With the goal of restoring the luster of agile approaches, which aren’t rusty – but what we’ve made of them is quite pathetic – I propose we ask ourselves a few simple but important questions.

One question: why do you do iterations? Everyone talks about iterations. It seems to be an indicator of an agile approach. My question, I repeat it, is therefore: why do you do iterations?

Why does agile propose doing iterations and how does this distinguish it from a classic project approach (waterfall, V-cycle, etc.)? And when V-cycle, waterfall, classic projects tell you we do iterations, how do they differ drastically? (or else, how do they have a so-called agile approach without knowing it?)

Take five or ten minutes to reflect before I influence you with my remarks, then I’ll come to my proposals.

5 minutes?

10 minutes?

…

…

Iterations serve to minimize risks and to optimize what you build or what you do. I’ll elaborate and this will imply certain consequences.

Minimize risks

Minimize risks by having an earlier look at what you’re doing. If you build something and you do “tada here it is” after a year, you take a one-year risk. If you build something that consists of an assembly of twelve times one month, you take twelve times a one-month risk. A one-month failure can be recovered much more easily than a one-year failure, and this has other advantages.

But consequence: for this, each thing that comes out during each of these months must be something you can truly assess. This thing that’s being built, being done, in twelve pieces every month cannot suddenly appear to you at the end of the assembly otherwise, unintentionally, you’ve taken a one-year risk and that’s precisely the option you wanted to avoid. This is generally the mistake of classic projects (waterfall, V-cycle) that tell you they do iterations, but whose real “tada here it is” is indeed only at the end of the cycle. The difficulty is therefore to think about what you’re building in order to have the ability to do “tada here it is” every month, or every two weeks, or every day, etc. The agile approach allows minimizing risks: the more effort you make to shorten these delays, the less risk you have; the less effort you make, the more risk you have. But you need to know how to do this particular, different breakdown (this isn’t the subject of this article, but you have quite a few articles on the subject in this blog).

And another consequence that follows from the first: you must be able to assess your “tada here it is” – does what you’ve achieved work? Because what risks are we talking about? We’re talking about the fact that what you’re doing is useful, has value. And so how do you assess at regular and – hopefully – short intervals that what you’re doing has value, is useful? Again, it’s up to you to set the cursor, but an agile approach will want to validate (therefore eliminate risks) by implementing what you’re doing or what you’ve built in real conditions: is it being used? Does it work? Is it liked? Does it fit? Etc., etc. The more you do this test in real conditions: for example by starting to distribute what you’ve built and having it used, the more you learn and know whether you’ve succeeded or failed, the more you reduce your risks. If you decide by looking at your development screen (for example) to say that it works, you’re distant from real conditions, you learn less, you don’t really know if it’s a success or failure, and the more you let the risk persist, and it grows over time.

Observations if therefore you don’t test as much as possible “in real conditions,” or if you don’t even look at the result of your iterations, on one hand you don’t have an agile approach (it’s not very serious) but above all: you’re taking big risks of heading toward disappointment later. Finally, doing iterations without benefiting from its value is above all putting teams or yourself under stress for no reason, and stress leads to bad things.

Optimize what we build or what we do

Optimize what we build or what we do by having this regular look mentioned above. A real look, at something whose relevance you can assess. It’s as if you opened a book every month (to use the example above), rather than every year. You discover every month (in our example) if your choices are the right ones, if they work, and this allows you to change or adapt every month (or every two weeks, or every day, etc., and not every year). When we start, we begin with hypotheses (more or less reliable), and when we’ve arrived at our destination our hypotheses have become answers (good or bad). If you have iterations, you have answers much more regularly, you don’t have the pain of waiting for the “here it is tada!!” after a year.

But this is true once again only if the consequences mentioned above are taken into consideration. You must be able to assess the relevance of what you deliver at regular intervals. This means that a non-agile approach is an assembly whose result is usable only at the very end of the cycle. And what makes an agile approach is that the result should be usable at regular intervals and it expands over time, because no, there’s no magic, we can’t have in one month what takes a year to achieve.

Consequence: after learning, the optimization possible at each of the intervals means what you do or build potentially (often) changes over time and doesn’t completely resemble (or not at all) what you had envisioned at the very beginning.

There you have it, I hope we’re in sync, and it should be easy for you now to tell yourself if you’re using iterations properly, and in the right way (if your goal is to have an agile approach, no, sorry, the term agile we don’t care about, rather: if your goal is to reduce risks and optimize the value or usefulness of what you do or achieve).