Hyper-productivity - just a short run ?

The Scrum marketing claims Hyper-Productivity. Sometime is true, sometime it is not. That depends on who make that claim...Which is the best way to validate that? We can measure, for example, the team velocity for a period of few months. It is that a correct approach?

Maybe the most know and severe problem in software development is the accumulation of the undesired complexity - Technical Debt. The main consequence of a such debt is the deterioration - in time - of the overall productivity and quality. 

Short "hyper-productive" runs with a lot of accumulated debt it is not Agile and it is not Scrum. Remember the principle from Agile Manifesto that require "sustainable development": "The sponsors, developers, and users should be able to maintain a constant pace indefinitely.". Scrum suppose that you will assess your work progress using the criteria of "Done": no other work is necessary on that product part, and that include very few Technical Debt.

Anyway, this kind of  "shortness of breath" it is very common and we must be able to identify and address the root causes. One cause it is the lack of skills of the involved team of developers, but another is related to the management.

"So how can you incent a Scrum team to not make a mess?"

This is a very good question, proposed by Robert C. Martin, in the article "The Land that Scrum Forgot"  that could be found here (with a forward by Mike Cohn):

http://www.scrumalliance.org/community/articles/2010/december/the-land-that-scrum-forgot/

Spoiler (from the article): "If the team goes fast and stays clean, then there is a reward!"

Usually only the project viewpoint it is the of interest for the management, because is focused on short term results. Anyway, the overall business should remain steady, and we should be interested on the product internal state, the amount of the accumulated undesired complexity.

The Scrum proposed by Jeff Sutherland it is Hyper-Productive (!), because in the same package we will found the requirement for technical excellence and outstanding enginnering practices such as TDD. For a such performance you need to read more than Scrum Guide and you need more others Agile skills and knowledge.