That is because percent complete is a lie to make burn down charts look good. In addition, the pain of telling the truth that at 20% complete you have discovered that whatever you are working on will take twice as long is greater over a greater period of time than pretending you can complete on time until you are "95%" done, at which point, you then deal with the pain of saying you need the extra time. That way you have avoided several weeks of annoyance and negative attention from management.
This is directly related to why all estimates are inflated because management punishes people for exceeding an estimate by 10%, but does rewards people when the work is done 30% under the estimate. Add to that the tendency to fill up the estimated time even when you do overestimate, and everything ends up costing way more than it should, and every one continues pretending that those pre-project estimates are actually accurate.
My take away from SCRUM, Agile, etc... Is "Stop lying to yourself". You don't actually know how many hours it will take to complete a software project. In part, because you and your customer either can't articulate or do not really know what you want until you see it. Accept the uncertainty and deal with it. So, it is much more effective to get something functional in front of your stake holders to discover what they really want, rather than spend a bunch of time writing documents and having meetings trying to figure out what everyone wants. Even if 50% of what was developed gets thrown out, you now have 50% of the work done in likely less time than it would have taken to have all those meetings and write the documents and get approvals.