The way to defeat crunch mode is data. If your velocity is 10 and you have 120 points left you probably aren't launching in 2 months. Engineers seem to shy away from metrics to describe their work because it's hard to quantify but it tends to work against them because they get trapped into unrealistic and non-data driven deadlines. Either the date has data backing it up or it's an arbitrary number.
This is exactly it. In my first software job, I found it very difficult to communicate the status of a project because we had no project management. I naively thought I was only a few brilliant coding sessions away from getting on top of things, but that slipped into a few more months of crunch mode.
Also, learning to say "no" is vital to preventing crunch mode. Wanting to please my superiors, I would typically say "yes, I'll do my best" or "maybe" when things were dire but never "no, that's not possible".
I'm not convinced data would defeat crunch mode. In your example, if a pointy-haired boss or incompetent project manager saw that the group's velocity is 10 and there's 120 points left, they would simply declare that the velocity must increase to 20 and demand everyone work extra to make it happen. Because, you see, they have already promised their boss and the client that the project will be ready in one month. Data simply empowers them to push the team into crunch mode.
Velocity only works if your project is large enough to have stable measures of velocity, but, really, it takes multiple project executions in a stable environment to get it right. That's not to say it can't be done, just that, under the conditions where it does work, you probably have smooth-running projects anyway.
