Re-planning in isolation is not a failure. I think re-planning is a failure when nothing is learned from previous assumptions not being correct, which usually leads to serial re-planning. I've seen this pattern form at practically every company I've worked for, in particular whenever there's a merger or a private equity buy-out. More often than not, this is ironically caused by leadership failing to learn from previous assumptions because they're too busy chasing the shiny new bobble of the week, but the blame still gets diffused across the organization.
> I think re-planning is a failure when nothing is learned from previous assumptions not being correct
This is the exact problem, and why it is so extremely difficult to communicate about the subject.
Another way to say "learn from previous [failures]" is "bureaucracy". We did something wrong last time, so we need a rule about that failure.
It SHOULD NOT be seen as failure, we SHOULD NOT add bureaucracy, simple rules CAN NOT fix the issue.
What should happen: Line managers and developers should be able to communicate about what they are learning as they do the work of software engineering. Developers should be able to re-plan their approach to problem solutions.
This simply will not work if there is not strong trust between upper management/[the money] and the engineering/execution side of the organization.
----
The meta-problem is that you have to see things go wrong many times in many ways before you really understand what is going on, and by that point ... well everything gets very tiresome.