I disagree with most of this article, but this part stood out:

> the size of the iterations matters, a whole lot. If they are tiny, it is because you are blindly stumbling forward. If you are not blindly stumbling forward, they should be longer, as it is more effective.

You are not blindly stumbling forward, you're moving from (working software + tiny change) to (working software including change). And repeat. If there's a problem, you learn about it immediately. To me that's the opposite of moving blindly.

> you really should stop and take stock after each iteration.

Who is not taking stock after every iteration? This is one of the fundamental principles of agile/lean/devops/XP/scrum. This one sentence drastically lowers my impression of the author's ability to comment on the subject.

> The faster people code, the more cleanup that is required. The longer you avoid cleaning it up, the worse it gets, on basically an exponential scale.

Unsafe tempo is as likely to happen in big-spec design projects as in small iterations. In fact, working in careful small iterations helps us manage a realistic tempo because we know we can't move faster than we can get things into production and evaluate.

The terrible outcomes listed in the same paragraph are linked to unwise practice and have nothing to do with small iteration size.

exactly - and this is what good agile attempts to address - implement (importantly) user-facing function in exactly the smallest size possible (also important) with those two things you can build, identify issues / questions / problems in the fastest feedback loop as possible

indeed, i would argue 'big iterations' are the ones where all the problems which the author mentions crop up in the first place!