[MobiusHorizons]

Of course! The article agrees with you

> Real speed exists. Real speed is what happens when the work is understood, the constraints are clear, the people involved know what they’re doing, and the decisions have been made cleanly enough that execution can happen without constant re-litigation.

I think the article is arguing against speed preventing the kind of planning and alignment that makes smooth delivery possible. Rushing is probably the easiest way to make mistakes that ultimately kill projects, credibility, or at least increase the costs in relational capitol, time and morale. Defaulting to a panicked frenzied state of mind is a perfect way to fail at delivering expedient results.

[ppalata]

Depends on the organisation as I've seen the opposite (excessive planning without taking action) too. I'm on the speed side of things nowadays because I was usually wrong when I thought that the "work is understood and the constraints are clear".

[jeremyjh]

Yes, the problem is the feedback loops often don't really exist in the planning stages. It is more difficult to gauge progress. There can be very detailed specifications or plans that won't survive their first contact with reality. This is why waterfall is over with.

Yet - not planning effectively is also a huge problem.

[daishi55]

So then the article boils down to, doing things well is good and doing things poorly is bad?

Not arguing against speed, just poorly-executed speed.

[Viliam1234]

If you assign speed-based KPIs to everything, you will get both the good speed and the bad speed.