But that's a big problem. Developer work is effectivly not measurable.
How do you measure code quality? Any "mechanical" method (counting lines, lint scores, whatever) can be very misleading, basically it can be shown by example that it measures the wrong thing.
How do you measure being on time? That strongly depends upon the guestimate that we all do in the start. In most methods, this "educated guess" is done by people who do not have to keep the time limits set.
Add to this that management usually does not understand what the developers are doing (the only thing you might count on is that your immediate superior has a vague idea what you are doing, in most places. The superior of your boss usually has your whole group condensed to one line, and so on), and it gets very hard to be appreciated as a developer. Hence older and more experienced developers often develop a cynic streak, leading to under performing. As long it's hard to prove that you are under performing, ...
Furthermore, customers usually do not realize that sprints where vaste amount of functionality gets implemented in very short time (with potentially not much sleep) are something that is not really easily reproducable. Sometimes the subject matter you are working on turns against you (it's way more time consuming to finish off these last half-dozen bugs and edge cases, because it usually involves a good measure of debugging).
Ah, and one last item that makes our job so hard to cast in work days, debugging. There are bugs that you write yourself, against these you can try to protect yourself. Then there are bugs that you inherit from internal modules, 3rd party libraries. Then we've got the whole area of problems associated with the customer not telling everything. Then we've got complete changes of functionality and focus midproject.
Does not happen? I had once a situation where a sister company refused to hand over any documentation beyond what the end customer had. So while we went to reverse engineering stuff that one trip to the sister company could have avoided; Why you wonder? In this case they had a real good reason, the systems they've sold to the customer did not what they were supposed to do. And our effort was to port some applications that would have enabled the customer to check the functionality through his own officers, not relying on the operators from the seller company; so they stonewalled us, while delivering "updates" to the customer, ...