Many software development methodologies have tools to measure speed: burndown chart, velocity tracking, story points, etc. The goal is admirable - to improve tasks estimation accuracy and to be consistent in resource allocation and planning.
Not an easy thing to achieve. And practice shows that despite all effort most teams still struggle with estimates. In reality this rpg-like game in measuring efficiency takes all the team focus (like most games do): calculate story points, track the burnout chart, move tasks on board from left to right.
It is not encouraged to change tasks during a sprint. Basically meaning that if you learned something new and the task needs to be changed accordingly you must wait a week or two till the current iteration ends.
This is bullshit. If one of the most important accomplishments during product development, learning something valuable and understanding how to make the product better, needs to wait for the process to catch up then where is agile and flexibility here?
Methodology works with speed as the main problem. It doesn’t ask for whom and what problem these user stories solve. It doesn’t track if the feature is successful in benefiting the user. All what it cares about is if the requirements are done in correct estimates.
That kind of methodologies divide those who write the requirements and those who make solutions for them. In such circumstances it is impossible for product to improve during the sprints because the highly skilled and smart team doesn’t take part in analysis and improving solutions for user problems.
In my experience one the most valuable insights and improvements happen during actual feature/product development. I believe that is because this is the rare time when the whole team is working on a problem. We shouldn’t exclude them from the product improvement process and focus just on the speed. Or you could accomplish what you aim for - complete the project quickly but make not what was needed or desired by the customers.