> 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.
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".
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.
> 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.