"What is Technical Debt?"

THAT IS THE QUESTION... and you should know (!) the answer to this question in order TO BE AGILE. If not, now it is good moment to start finding more info on this subject.

Well... it is possible also to know the problem, but not with this formal name. 

Anyway, dealing with TD it is matter of TO BE OR NOT BE AGILE.  The full set of questions is:

• What is TD?
• How could be solved and/or managed?
• Do you use as a criteria for work assessment to have a low(enough) level of TD?

Just a hint: Scrum has the concept of "Done". In fact you are not really Done, if there is too much TD left behind at the end of Sprint work. That mean TD it is a matter of  "To be or not to be" also for Scrum adoption.

More: TD it is an "Elephant in the Room" for Agile, but also for Software Development as domain of activity (no matter the used process approach).