Thread by @RonJeffries

Someone didn’t ask what iterations are good for. Iterations are good when, like other artificial constraints, they teach us something. What can they teach us? At least two things, Done, and Flow.
/1

First, “Done”. The point of an iteration is to deliver an increment of the product, as complete, working, tested, done as possible, in that tiny little time period. Many dev teams haven’t even managed to do that in a year.
/2

They can learn, if they try, and with help, to get a slice of work really done, in a week or two or even less time. That’s good, because getting things done was probably the point of the effort.
/3

Then, “Flow”. There are two aspects here. First, the flow of features. With Done software in hand, the notion of “do all this stuff and then release” can be turned into “Do this next and release”, or even “Release now, then do this next”.
/4

That kind of flow delivers value to users sooner, returns value and information to the builders sooner. It’s a win-win.

But wait, there’s more.
/5

Working in iterations also helps us see what’s holding things up. We see internal handoffs, and reduce or remove them. That’s flow.

We see delays elsewhere in the decision flow, and fix those. That’s flow.
/6

We see all the impediments to producing and releasing increments of value. Impediments are precisely “things that get in the way of flow”.

Iterations produce “Done”, and they produce “Flow”.

Q.E.fucking.D
/6 end